Closed Bug 545722 Opened 13 years ago Closed 13 years ago

address bar "jumps" when it gets focus


(Firefox for Android Graveyard :: General, defect)

Fennec 1.1
Not set


(Not tracked)



(Reporter: blassey, Assigned: mbrubeck)




(1 file)

I believe this is a regression from bug 544898
tracking-fennec: --- → ?
Yes, this is a regression from bug 544898.  This bug goes away after reverting  these lines from chrome/content/browser.js:421 added by that fix:

      let curEl = document.activeElement;
      if (curEl && curEl.scrollIntoView)

This is not 100% reproducible.  It seems to happen more reliably when the
Fennec window is smaller.  From the duplicate bug 554522, steps to reproduce:
1. Launch fennec with no arguments.  The history popup opens automatically.
2. Without entering/choosing any URI, click the urlbar close button at the top
right corner.
3. about:blank is displayed with urlbar scrolled up by 21px.

When about:blank is loaded, document.activeElement is the html:input in the urlbar.  Calling scrollIntoView is scrolling this element to the very top of the window.
Assignee: nobody → mbrubeck
The problem is that scrollIntoView tries to align the element with the top of the screen even if it is already visible; when the element is the urlbar textbox, this causes the urlbar to jump up unnecessarily.

Using scrollIntoView(false) aligns the element to the bottom of the screen instead.  This fixes the problem with the urlbar, and I think it's slightly better in general (since the problem in bug 544898 was elements at the *bottom* of the screen being hidden by the software keyboard).

It would be nice if scrollIntoView() had no effect on elements that are already "in view" but I couldn't find a really simple test for whether an element is on screen.  Any suggestions?

One-line patch attached.
Attachment #434705 - Flags: review?(mark.finkle)
Comment on attachment 434705 [details] [diff] [review]
patch - use scrollIntoView(false)

Works on device
Attachment #434705 - Flags: review?(mark.finkle) → review+

When verifying this, I would be great to see if bug 544898 wasn't regressed. I don't know if we still have a WinMo build you could try. I guess we could verify on Android too?
Closed: 13 years ago
Resolution: --- → FIXED
I tested for regression by manually resizing the window in desktop Fennec.  With the fix for bug 544898 reverted I could reproduce that bug, with the fix in place I could not (with or without my own patch).

But yeah, it would be good to verify on a device with soft-keyboard too.

I don't have winmo hardware; is there any emulation available?  For Linux, or would I need a Windows VM?
tracking-fennec: ? → ---
You need to log in before you can comment on or make changes to this bug.