mouseEnter/mouseExit event is triggering a screen jump ONLY when zoomed in?

Avatar

Avatar

Brian3_14

Avatar

Brian3_14

Brian3_14

10-10-2014

Hi all:

First and foremost, to all the people who repeatedly post answers: you are truly rock stars in my book.  Learned so much from you all; deepest, deepest thanks.

I can't find anything online re: this issue, and BELIEVE me I've looked, so I'm going to do a detailed post with a detailed example.   If I do a good enough post, maybe that helps someone else out down the line.

Using LiveCycle Desiger to create a dynamic PDF.

Conditions

     When:

     1) A field has focus; (and)

     2) The end-user ZOOMS IN on the form;(and)

     3) The end-user decides to scroll away from the field with focus (so the field with focus is no longer visible on the screen but still technically has the focus)

The Issue:

     If the cursor happens to go over an object with mouseEnter or mouseExit code, Acrobat will jump the view back to the field with focus.

   

Practical example:

     1) End user opens a PDF and zooms in a little for easier reading.

     2) End user sets focus to a field at the top of the page to answer that question.

     3) End user decides to scroll down and see what other types of questions they have to answer, leaving the focus still in the top field;

     4) If the screen scrolling passes the cursor over an object with javascript in the mouseEnter or mouseExit event, Acrobat resets the view back up to the top of the page so

          the field with focus is visible again.

          Note: Even If the screen scrolling doesn't pass the cursor over an object with script in the mouseEnter or mouseExit event, if the end-user then moves the cursor over an

                    object with code in the mouseEnter or mouseExit event, Acrobat resets the view so the field with focus is visible again.

Additional Comments

     1) Object type doesn't seem to matter.  I tested it on additional field types in the attached and the jump seems to be triggered when code exists in the mouseEnter or mouseExit

          event and the field with focus is NOT visible on the screen.

     2) It doesn't appear to be a "top" or "bottom" of page issue.  Page 2 of the attached reverses the layout from "top-to-bottom" to "bottom-to-top" and the jump still occurs.

     3) It appears to be a Dynamic Form issue as I did a save as a Static PDF and the jump does NOT occur.

     4) Happens on both PC and Mac.

The attached is heavily noted and contains multiple buttons demonstrating the various conditions and what does or does not trigger the jump.

Thoughts?  I'm totally stumped.  A form level property that is trying to help???

Thanks in advance,

BR

(Couldn't attach PDFs for some reason.  Here's a dropbox link.  Dropbox - Public

Accepted Solutions (1)

Accepted Solutions (1)

Avatar

Avatar

radzmar

MVP

Total Posts

2.7K

Likes

387

Correct Answer

485

Avatar

radzmar

MVP

Total Posts

2.7K

Likes

387

Correct Answer

485
radzmar
MVP

13-10-2014

You'll have to reset the current focus to get rid of the jumping focus.

Add this additional function to your form.


function resetFocus (obj) {


  var focussed = xfa.host.getFocus();


  if (focussed !== null) {


  if (focussed.somExpression !== obj.somExpression) {


  xfa.host.setFocus(null);


  }


  }


}


Call this function from the buttonOnEnter() function


function buttonOnEnter(btn){


  resetFocus (btn);


  btn.border.fill.color.value = vColorMouseEnter.value;


  }


Answers (5)

Answers (5)

Avatar

Avatar

Brian3_14

Avatar

Brian3_14

Brian3_14

16-10-2014

I don't think there's going to be a perfect solution to this problem, other than an official Adobe fix. (That's a big hint there, Adobe.)  BUT...

... that being said, I think Radzmar's work-around is the best answer out there. Big thanks, R.

IMPORTANT DESIGN CONSIDERATION FOR ANYONE USING THIS SOLUTION

Please keep the following in mind when designing your forms:

1) Message Box location

CONDITIONS:

               1) It's possible you are going to validate a field on exit;

               2) It's possible you're going to inform the end-user of failed validation with a messageBox;

               3) It's possible you're going to reset the focus back to the field that failed validation so the end-user is forced to correct it.

               4) It's possible you want to keep the inputted data that failed validation so the end-user can see the entry that failed and edit it,

                    rather than retyping the whole thing.

BE AWARE OF:

               1) When the message box appears, the end-user will have to either hit return (to acknowledge the messageBox) or click "OK" to do the same;

               2) If the end-user uses the mouse to click "OK", that starts the mouse moving around the page again;

               3) End-user may attempt to place the cursor in the appropriate location within the field that failed validation to correct the error;

               4) BUT if the cursor passes over any objects with script in the mouseEnter or mouseExit event ON THE WAY BACK TO THE FIELD WITH FOCUS it will:

                    a.) trigger the clear focus script;

                    a.) which will trigger the validation script in the exit event of the field with focus again (WHICH STILL HAS BAD DATA IN IT);

                    b.) which will trigger the messageBox re: failed validation;

                    c.) which trigger's potential mouse movement to again click  "ok"

                    d.) and you see the loop they'll end up in.  They'll have to move the mouse AROUND buttons/objects with mouseEnter or Exit code to get

                         back to the field which needs to be corrected.

So it's the combination of:

     1) Where objects with mouseEnter and mouseExit code are placed on the page; and

     2) Automatically resetting the focus BACK to the field that failed validation; and

     3) Keeping the failed data in that field.

Unless anyone see's a work-around, I think the only thing to do is clear that failed data out of the field.  Not optimum, as the end-user won't be able to see their failed answer

but I'm not seeing another option???

BR

Avatar

Avatar

jnicholas330

Avatar

jnicholas330

jnicholas330

14-10-2014

I tested this solution, and it "works", but I believe the solution may be worse than the problem. By resetting the focus all the time, the user get an experience different than a web page form, which allows focus to remain on fields that are off screen.

Avatar

Avatar

jnicholas330

Avatar

jnicholas330

jnicholas330

12-10-2014

We didn't. If the issue is indeed the mouseEnter and mouseExit event, I suppose I could remove them as they only add visual embellishments.

Avatar

Avatar

Brian3_14

Avatar

Brian3_14

Brian3_14

11-10-2014

Thanks for the comment; wish neither of us had to discover this.  This discovery essentially kills my entire design if there's no work around.

I'm new to all of this so if some code wasn't working or something wasn't doing what I intended, the logical person to blame was me. And I went back and found and fixed my errors.

But if this is truly a bug within the system???  Can't see how this one got through.  The potential of an end-user zooming in and then scrolling to look around seems so obvious.    

Devastating.  I was almost done.

OK.  Self-pity ain't gonna solve the problem.

How did you get around yours? 

Avatar

Avatar

jnicholas330

Avatar

jnicholas330

jnicholas330

10-10-2014

I also have this issue, but never took the time to reproduce it. Hopefully someone from Adobe will see this and fix it, as I can't believe this is the desired behavior.