1048067 - giving .focus() to input type=search causes transform to fail

Status: UNCONFIRMED

(Core :: General, defect)

Description

[jason]

Attachment: scr.jpg

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0 (Beta/Release)
Build ID: 20140728123914

Steps to reproduce:

We have a fairly complex layout that has two off-canvas navigation menus, one of the triggers to activate it also gives .focus() to an input type=search within the nav menu. The method to do this worked in FF30, but in FF31 and beta channel (FF32) this now causes the translate to move too far across the screen. Additionally, a soft-reload leaves the page in a different malfunctioning state (I think this might be caused by transforms not resetting to origin). I have been able to fix this by either

* Not giving .focus() to the search input, or
* Changing to type=text on the input

To recreate on the our production site, go to

  https://vca.unimelb.edu.au

Add the following event handler in console

document.querySelector('a[title="Search"]').addEventListener('click', function(e){ document.querySelector('input[type="search"]').focus(); });

And click the "Search" button.

Obviously this is not a massive problem for us (I've already worked around it), but the combination of js + css worked correctly in FF30, so it looks like a regression has been introduced in the latest stable.


Actual results:

The 2nd menu translates too far to the left and exposes the 1st menu (see attached, top half)


Expected results:

See attached (bottom half)

Comment 1

[Markus Stange [:mstange]]

When something is focused, Firefox attempts to scroll it into view. So what happens might be that the scroll offset of some element (or the viewport) is changed unexpectedly, but not the transform. Firefox also tries to restore scroll offsets when a page reloaded, which would explain the stickiness of the problem.
Does this already help? I haven't looked at the page in much detail. I also don't know if Firefox will change the scroll offset of overflow:hidden elements. If it does, does setting overflow:-moz-hidden-unscrollable help?

Comment 2

[jason]

Thanks for the reply Markus, I tried adding -moz-hidden-unscrollable but it didn't fix this problem for me (unless I'm adding it to the wrong element - I assume it needs to go on the transforming element?)

You reminded me of another thing though - FF30 and earlier didn't need offset-x:hidden for this off-canvas transform to work, but FF31+ no longer hides off canvas elements unless you explicitly set offset-x:hidden. All other browsers hide transformed elements without needing overflow set.