Steps to reproduce: 1. Go to https://dl.dropboxusercontent.com/u/95157096/85f61cf7/qozqxd7g72.html. 2. Open the <select> element. Actual results: The selected value does not appear when open the <select> popup. Screenshot https://dl.dropboxusercontent.com/u/95157096/85f61cf7/uufncl2zhw.png

Regression range: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=7cd48e5cb14c647f86faa98628301959b86393cb&tochange=9b361e455e6ab4c37c9368d5b9c914b22997efb7

suspect: Bug 1253975

The issue here is that the scroll positioned is assigned during the popupshowing event, before the popup has been clipped to the screen and/or window bounds. One easy solution is to use the upcoming popuppositioned event (bug 1206133) instead which fires after the popup's position and size has been assigned. It might cause some minor delay in opening the popup however.

[Tracking Requested - why for this release]: Regression in 50 related to select popups.

Tracking 52+ for this regression related to popups.

Track for 51+ as this is a regression related to select popups.

New regression in Fx50, tracked.

This happens here too https://dl.dropboxusercontent.com/u/95157096/85f61cf7/483nx2q1ck.htm. Screenshot https://dl.dropboxusercontent.com/u/95157096/85f61cf7/alot2vjfag.png

Doesn't hurt to scroll the current item into view after opening the popup.

Add some tests. Kirk offered to try having a go at reviewing this.

Comment on attachment 8798844 [details] [diff] [review] Scroll current item in menulist into view when opening Review of attachment 8798844 [details] [diff] [review]: ----------------------------------------------------------------- Looks good! Just a few little things I wanted to mention. ::: browser/base/content/test/general/browser_selectpopup.js @@ +63,5 @@ > " src='data:text/html,<select id=select autofocus><option>he he he</option><option>boo boo</option><option>baz baz</option></select>'" + > "</iframe>" + > "</div></body></html>"; > > +function openSelectPopup(selectPopup, withMouse, selector = "select", win =window) Formatting nit: Should be |win = window|. ::: layout/xul/nsMenuPopupFrame.cpp @@ +536,5 @@ > > + // Make sure the current selection in a menulist is visible. > + if (IsMenuList() && mCurrentMenu) { > + EnsureMenuItemIsVisible(mCurrentMenu); > + } Since we are doing this here, do we want to remove the code that used to do this? http://searchfox.org/mozilla-central/rev/fd672b97f13aa83af5f04caa7b61bd443fb623e9/layout/xul/nsMenuFrame.cpp#554

(In reply to Kirk Steuber [:bytesized] from comment #11) > > Since we are doing this here, do we want to remove the code that used to do > this? > http://searchfox.org/mozilla-central/rev/ > fd672b97f13aa83af5f04caa7b61bd443fb623e9/layout/xul/nsMenuFrame.cpp#554 No, it would just add more complexity and that code would still be needed for non-menulists.

https://hg.mozilla.org/integration/mozilla-inbound/rev/232b53f8089353e749954fb094ee84783283207e Bug 1304243, scroll the current item into view when opening a menulist after it gets positioned so that it scrolls properly if the popup gets cropped, r=ksteuber

Neil, this is tracked as a new regression in 50, if you think this can be uplifted would you mind filling the uplift request?

Comment on attachment 8798844 [details] [diff] [review] Scroll current item in menulist into view when opening Approval Request Comment [Feature/regressing bug #]: 1253975 [User impact if declined]: the selected item in a <select> is not visible for large lists [Describe test coverage new/current, TreeHerder]: tests included [Risks and why]: minimal, the patch just adds a scroll into view call [String/UUID change made/needed]: none

Hello blinky, could you please verify this issue is fixed as expected on a latest Nightly build? Thanks!

Comment on attachment 8798844 [details] [diff] [review] Scroll current item in menulist into view when opening Fixes a new regression in Fx50, Aurora51+, Beta50+

(In reply to Ritu Kothari (:ritu) from comment #18) > Hello blinky, could you please verify this issue is fixed as expected on a > latest Nightly build? Thanks! I can not reproduce this bug with the latest Nightly build.

I'm hitting a conflict applying this to beta. Could we get a rebased patch?