545722 - address bar "jumps" when it gets focus

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Brad Lassey [:blassey] (use needinfo?)]

I believe this is a regression from bug 544898

Comment 2

[Matt Brubeck (:mbrubeck)]

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.

Comment 3

[Matt Brubeck (:mbrubeck)]

Attachment: patch - use scrollIntoView(false)

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.

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 434705 [details] [diff] [review]
patch - use scrollIntoView(false)

Works on device

Comment 6

[Mark Finkle (:mfinkle) (use needinfo?)]

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?

Comment 7

[Matt Brubeck (:mbrubeck)]

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?