Closed Bug 545722 Opened 10 years ago Closed 10 years ago
address bar "jumps" when it gets focus
I believe this is a regression from bug 544898
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) 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
Status: NEW → ASSIGNED
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+
pushed: http://hg.mozilla.org/mobile-browser/rev/7e1b6d5168fe 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?
Status: ASSIGNED → RESOLVED
Closed: 10 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?
You need to log in before you can comment on or make changes to this bug.