1468410 - Inputs within Fixed Position Wrappers Unfocusable - Can't Type, Copy, or Select Text in Textareas & Inputs - Certain Scenarios

Status: NEW

(Core :: DOM: UI Events & Focus Handling, defect, P2)

Description

[Eric]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180605171542

Steps to reproduce:

I've noticed that depending on what HTML markup and CSS styles are used that some inputs within fixed positioned containers are not focusable.  Simply put, you cannot interact (input text, select text, or copy text) with some inputs when many fixed position divs are used with different z-index values.

This is a very strange bug because it took me forever to put together a reproducible sample.  Granted, this sample is using the Magnific popup jQuery plugin (http://dimsemenov.com/plugins/magnific-popup/), but after scouring the HTML and styling Magnific Popup produces, I see no reason for the input field to NOT be interactable or focusable.  If you remove the overflow styling from the top most fixed layout magnific container (from .mfp-wrap), you can then interact with the input shown in the sample.

Here is a fiddle that has an input field that you cannot interact with.  However, you can in Chrome, which therefore leads me to believe something is broken in Firefox.

http://jsfiddle.net/gp4b9chs/53/

Notice how in Chrome you can type text into and interact with the input.  However, with the latest version of Firefox, you cannot.  

Granted, if you add a tabindex attribute on the (.mfp-wrap) element, this will prevent the input from being interacted with in Chrome and Firefox as shown here:

http://jsfiddle.net/rvtmqs6k/

tabindex is a separate issue altogether though, but I find it strange that z-index styling does NOT override tabindex attributes set on elements that will be covered by other elements with higher z-index values.  Covered elements are not focusable no matter what tabindex you provide (at least that's how I'd imagine it works).  


Actual results:

Main Input Editable & Interactable in Chrome:

http://jsfiddle.net/gp4b9chs/53/

Main Input Not-Interactable in Firefox:

http://jsfiddle.net/gp4b9chs/53/


Expected results:

Should be able to interact with input in all browsers.

Different HTML structural markup produces results that should work, so I'm not sure what styling is throwing Firefox out of whack when it comes to Magnific popup except that Magnific popup uses some absolute positioned elements within a fixed position wrapper (which is not needed).  However, it should still work.  

Here's a cleaner markup example that I wrote where everything works in both Firefox and Chrome, so I was unable to discover exactly why the behavior of Magnific popup's HTML and CSS causes different browser behavior in the bugged sample:

http://jsfiddle.net/gp4b9chs/30/

This is a complicated bug, and I'm so amazed that web browser engineers are even able to support all this craziness, but this use case should work.

Comment 1

[David Olah]

Hi Eric,

Thank you for taking the time to log this issue!

I managed to reproduce it on Nightly 62.0a1 (2018-06-15), FF 61.0b13 and FF 60. OSes: Windows 10, Ubuntu and Mac OS.

Marking it as New on Event Handling component.

Comment 2

[Andrew Overholt [:overholt]]

Botond, do you think this is similar to bug 1296776?

Comment 3

[Botond Ballo [:botond]]

It should be unrelated, since bug 1296776 is specific to pinch-zooming (and thus, currently, to mobile), while this bug reproduces on desktop.

Comment 4

[Andrew Overholt [:overholt]]

OK, let's ask Olli to take a look when he's back.

Thanks for the report, Eric! And thanks to Botond for his thoughts.

Comment 5

[Botond Ballo [:botond]]

Attachment: Testcase

Here is the testcase packaged as a single file.

Comment 6

[Botond Ballo [:botond]]

Attachment: Frame tree

Here is a frame dump of the testcase.

Comment 7

[Botond Ballo [:botond]]

I've verified that main thread hit test for a click on the <input> element hits frames inside the nsTextControlFrame created for it, suggesting that the problem doesn't lie with main thread hit testing either.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

I'm missing something here. I can click the input element in the testcase and it gets focus and I can type and cut and paste etc.

Comment 9

[Botond Ballo [:botond]]

Attachment: Testcase

Comment 10

[Botond Ballo [:botond]]

Looks like Bugzilla refuses to allow an attachment to load scripts/css over HTTP. Changing the referenced links to HTTPS should make the attachment work.

Comment 11

[Botond Ballo [:botond]]

(Which I've done in the updated attachment.)

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

Still working fine.

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

So looking at the jsfiddle I can see the issue. Something is explicitly moving the focus out from the input element to div element with classes 
mfp-wrap mfp-close-btn-in mfp-auto-cursor mfp-readySetCaretVisible
and that is an element from Magnific plugin. This is starting to smell like a Magnific bug.

Comment 14

[Eric]

Strange.  Do you know specifically what CSS class or JavaScript line is causing the problem?  I'm betting it is a Magnific bug, but I found it strange that Chrome had the input focasable just fine.  So, does that mean there's a bug with Chrome (aside from there being an issue most likely in the Magnific code)?

Comment 15

[Olli Pettay [:smaug][[e-mail]]]

I'd expect the plugin does something browser specific, or jQuery. jQuery has at least traditionally done quite some browser specific things. But I guess I need to investigate some more.

Comment 16

[Eric]

OK, I finally figured this out. The problem appears to deal with the tabindex attribute set to "-1" to prevent elements outside of a modal from being focused. This was done on purpose by the author of Magnific Popup:

https://github.com/dimsemenov/Magnific-Popup/issues/340

As one user points out though, it might not be needed, as it causes problems in Firefox:

https://github.com/dimsemenov/Magnific-Popup/issues/340#issuecomment-462848080

The Firefox handling of the tabindex property causes problems in certain cases. An example is in the case I reported initially. In the initial bug I reported, the z-index content is covering other elements that have their tabindex attribute set to "-1". Another case is that content rendered outside of tabindex="-1" content cannot be interacted with or focused even though the z-index is greater than the element set with the tabindex of "-1". Try to change the year in this jQuery UI datepicker select:

http://jsfiddle.net/betfoz8j/4/

Should I report another bug with this information? I believe the title for this bug should be "tabindex, z-index, layering / covering, and focus issues in different scenarios".

I believe tabindex should be respected, but content with a higher z-index should be focusable regardless of any element's tabindex setting if the z-index value is higher than the original tabindex element.

A lot of plugins render elements in absolutely positioned containers outside of the original elements, and this causes problems in Firefox. So, the spec may need to be edited because it appears to be broken.

Comment 17

[Eric]

OK, I finally figured this out. The problem appears to deal with the tabindex attribute set to "-1" to prevent elements outside of a modal from being focused. This was done on purpose by the author of Magnific Popup:

https://github.com/dimsemenov/Magnific-Popup/issues/340

As one user points out though, it might not be needed, as it causes problems in Firefox:

https://github.com/dimsemenov/Magnific-Popup/issues/340#issuecomment-462848080

The Firefox handling of the tabindex property causes problems in certain cases. An example is in the case I reported initially. In the initial bug I reported, the z-index content is covering other elements that have their tabindex attribute set to "-1". Another case is that content rendered outside of tabindex="-1" content cannot be interacted with or focused even though the z-index is greater than the element set with the tabindex of "-1". Try to change the year in this jQuery UI datepicker select:

http://jsfiddle.net/betfoz8j/4/

It will not work in Firefox, but it does work in Chrome

Should I report another bug with this information? I believe the title for this bug should be "tabindex, z-index, layering / covering, and focus issues in different scenarios".

I believe tabindex should be respected, but content with a higher z-index should be focusable regardless of any element's tabindex setting if the z-index value is higher than the original tabindex element.

A lot of plugins render elements in absolutely positioned containers outside of the original elements, and this causes problems in Firefox. So, the spec may need to be edited (if there is one) because it appears to be broken.

Comment 18

[Eric]

Sorry for the duplicate comment... can't seem to change the first one... I second comment is the one I want people to read.