988265 - CSS z-index of 9999995 or greater prevents inserted <input> from gaining focus, at https://parse.com/ , due to exponential notation in computed style & JQuery manual z-index comparisons

Status: RESOLVED DUPLICATE of bug 470769

(Core :: Web Painting, defect)

Description

[Matthew Gertner]

Our extension is injecting a <div> into the current webpage with some form elements in it. We use a high z-index (e.g. 10^9) to ensure that the <div> is always on top of the page.

On pages that use a modal dialog (tested with parse.com and click Login), the form elements in the injected <div> refuse to take focus when clicked. After some experimentation, it seems like it works fine until the z-index reaches 9999995. I can't see any rational explanation for this so I'm assuming it's a bug.

Comment 1

[Daniel Holbert [:dholbert]]

Can you attach a testcase demonstrating the bug?

From my quick testing, it seems that we do honor z-index:[huge number] as being in front of z-index:[small number], for arbitrarily-large huge numbers.

However, we don't necessarily distinguish between huge numbers -- e.g. [huge number] may not stack in front of [huge number - 1], for sufficiently large numbers. Is that the problem you're seeing?

Comment 2

[Daniel Holbert [:dholbert]]

e.g. on my system, this renders as red (in Chrome, Opera, and Firefox), even though the red div has a lower z-index than the lime div (1 less):

data:text/html,<div style="position:absolute; top:0; background:lime;z-index:2147483648">abc</div><div style="position:absolute; top:0; background:red;z-index:2147483647">abc</div>

If you decrease the z-index of the red div by 1, then it renders as lime for me, though.

(2147483647 is the maximum z-index value we can represent, since it's the maximum value of a 32-bit signed integer (2^31 - 1). We parse it as a 32-bit signed integer due to the "I" in VARIANT_AHI here:
http://mxr.mozilla.org/mozilla-central/source/layout/style/nsCSSPropList.h?rev=887bdaaf9829&mark=3459-3459#3452 )

I'm concerned that the 9999995 value you mentioned is significantly less than 2147483647, though. If you're really seeing weirdness in the ballpark of 9999995, then it sounds like something might be broken (and a testcase would be useful).  I tried a modified version of my data URL above with <input> instead of "abc" and with z-index values in the range of 9999995, and I was able to give focus to the <input> fields. (I am on Linux, though, so maybe this is mac-only?)

Comment 3

[Matthew Gertner]

The high z-index elements do appear in from of lower z-index elements but if they contain form elements, the form elements refuse to take focus (e.g. you can't type into a text field). You can test this by placing a <div> with some <input> fields and a very high z-index into a page. It you still can't reproduce, let me know and I'll see if I can strip down my extension. I've only tested on Mac so it could be Mac-only.

Comment 4

[Matthew Gertner]

I just tried it on Windows and the problem occurs there as well. It might well be related to some shenanigans that parse.com is doing when you open the modal Login dialog (i.e. covering the whole page with a modal overlay). When the high z-index div is display in the normal page it works fine. But when I click the Login button then I get the behavior I described.

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Matthew Gertner from comment #3)
> but if they contain form elements, the form elements refuse to take focus (e.g. you
> can't type into a text field). You can test this by placing a <div> with
> some <input> fields and a very high z-index into a page

This works fine for me:
data:text/html,<div style="position:absolute; top:0; background:lime;z-index:2147483647"><input>

Seems like we need a testcase of some sort.

Comment 6

[Matthew Gertner]

(In reply to Daniel Holbert [:dholbert] from comment #5)
> This works fine for me:
> data:text/html,<div style="position:absolute; top:0;
> background:lime;z-index:2147483647"><input>
> 
> Seems like we need a testcase of some sort.

Again, it works fine in isolation. The problem occurs when their is a modal dialog on the page. Try this:
1) Go to parse.com.
2) Click on Login to display the modal dialog.
3) Open the Inspector.
4) Right-click on <body> and select "Edit as HTML".
5) Add <div style="position:absolute; top:0; background:lime;z-index:2147483647"><input></div> right after the <body> tag.

Note that you can't focus or enter text into the input field. Now change the z-index in the CSS pane to 9999995. Still can't focus or enter text. Now change to 9999994. It works!

Comment 7

[Matthew Gertner]

> Again, it works fine in isolation. The problem occurs when their is a modal dialog on the page. Try this:
s/their/there

Comment 8

[Daniel Holbert [:dholbert]]

Thanks! I can reproduce with those steps. (using Linux nightly)

Comment 9

[Matthew Gertner]

(In reply to Daniel Holbert [:dholbert] from comment #8)
> Thanks! I can reproduce with those steps. (using Linux nightly)

Great!

Comment 10

[Daniel Holbert [:dholbert]]

Simpler STR:
 1. Visit https://parse.com/
 2. Click "Log in" button.  [IMPORTANT.]
 3. Ctrl+Shift+K to bring up Web Console
 4. Execute this script:
document.documentElement.innerHTML = "<div style='position:absolute; top:0;z-index:9999995'><input>"
 5. Try to click in the <input>

If you change the "9999995" to "9999994" in the STR, it works correctly.

I'm guessing the Log In button must be setting up some weird click handler or something, since this happens even after the whole DOM has been replaced.

Comment 11

[Matthew Gertner]

(In reply to Daniel Holbert [:dholbert] from comment #10)
> I'm guessing the Log In button must be setting up some weird click handler
> or something, since this happens even after the whole DOM has been replaced.

Yeah I noticed that too. Note that https://github.com/bgrins/spectrum/issues/40 reports the same problem so whatever weird thing that site is doing is probably due to jQuery UI modal dialog behavior.

Comment 12

[Daniel Holbert [:dholbert]]

Yeah -- setting innerHTML (per comment 10) at this page, from that github issue...
 http://fiddle.jshell.net/9bLJK/19/show/
...triggers the bug, too.

(You have to use Tools | Web Developer | Web Console to open the console, since the page seems to absorb all keypresses, neutering ctrl+shift+k.)

(The source jsfiddle for that page is http://jsfiddle.net/9bLJK/19/ )

Comment 13

[Daniel Holbert [:dholbert]]

I hit the same issue with z-index values of 1000 or less, too. (but 1001 works)

Comment 14

[Daniel Holbert [:dholbert]]

Reduced jsfiddle (no web console interaction necessary): http://jsfiddle.net/K9b72/2/

Comment 15

[Daniel Holbert [:dholbert]]

reduced a bit more: http://jsfiddle.net/K9b72/3/

Comment 16

[Daniel Holbert [:dholbert]]

If I run "$.ui.dialog.overlay = null" in the context of the page, when the bug is reproducing, then the bug goes away. So this is from some stuff running on that object.

The JQuery UI js file includes this:
===========
$.extend( $.ui.dialog.overlay, {
[...]
  $( document ).bind( $.ui.dialog.overlay.events, function( event ) {
    // stop events if the z-index of the target is < the z-index of the overlay
    // we cannot return true when we don't want to cancel the event (#3523)
    if ( $( event.target ).zIndex() < $.ui.dialog.overlay.maxZ ) {
       return false;
    }
  });
============

When I click the input element, we hit that comparison and return false.

zIndex() is a function defined by jquery. I'm guessing the 9999995 threshold is an arbitrary cutoff imposed by that function.

Comment 17

[Daniel Holbert [:dholbert]]

(and $.ui.dialog.overlay.maxZ  here is 1001, which explains the 1001 threshold in comment 13)

Comment 18

[Daniel Holbert [:dholbert]]

zIndex is implemented as
 parseInt( elem.css( "zIndex" ), 10 )

Looks like elem.css is basically getComputedStyle. And it seems that 9999995 is the cutoff where we start returning exponential notation, "1e7", which parseInt parses as "1".

Comment 19

[Daniel Holbert [:dholbert]]

which means this is basically a dupe of bug 470769, I guess.