1053398 - Missing Input boxes on forums, or input box that you cannot type into

Status: VERIFIED FIXED

(Core :: XBL, defect)

Description

[Jim Jeffery not reading bug-mail 1/2/11]

Input boxes on forums, forms, and Google are missing, or cannot take text input, no cursor is displayed. 

Best STR I can find at the moment:
1.  Install the suspect bad build
2.  Close/Restart the browser 2 or three times, usually by 3rd time the boxes are missing

To Clear the problem start in Safe-mode, then restart normally.  Subsequent restarts will manifest itself again.

Bad: 20140812072957 ee1ad12a3939
Good: 20140811230756 b53c2753ce9a


Not sure its related or when it started but there is this error in Browser Console when opening tabs or starting the browser:

Error: chrome://browser/content/browser.xul : Unable to run script because scripts are blocked internally

Tested on Win7 x64 from tinderbox builds as noted above.  Same occurs in a fresh Profile/No Addons

Comment 1

[Jim Jeffery not reading bug-mail 1/2/11]

Is it possible but 1050049 is causing input boxes to disappear ?

cc: bholley

Comment 2

[Alice0775 White]

Regression windoqw(m-i)
Good:
https://hg.mozilla.org/integration/mozilla-inbound/rev/d78a39f01102
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140811200055
Bad:
https://hg.mozilla.org/integration/mozilla-inbound/rev/9648b3e555db
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140811200755
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d78a39f01102&tochange=9648b3e555db

Regressed by Bug 1050049

Comment 4

[:Gijs (he/him)]

Bobby, that's 3 dupes over the past 8 hours... :-(

Comment 5

[Bobby Holley (:bholley)]

(In reply to :Gijs Kruitbosch (intermittently here 14-15 August; then away until 19th) from comment #4)
> Bobby, that's 3 dupes over the past 8 hours... :-(

Presumably, the appropriate in-content XBL binding just needs to set bindToUntrustedContent=true (which is now required for a binding to be applied to a non-SystemPrincipaled Element). And it's really easy to figure out which one that is - just run a debug build, and grep for the helpful "denied" message in the terminal spew.

I'm happy to do that, but it's probably smarter to have someone familiar with the frontend do it, because they'll notice other things that might need to be whitelisted, and can write test coverage to boot. Gijs, can you or someone do that? If not I'm happy to write the minimal patch (and land it once the tree re-opens).

Comment 6

[:Gijs (he/him)]

These are meant to be regular text input fields on web pages... I'm kind of surprised that they would have a XBL binding.

Modified opt build (removed the #ifdef DEBUG, used printf instead - was quicker than rebuilding dbg w/ clobber):

Permission denied to apply binding chrome://global/content/platformHTMLBindings.xml#inputFields to unprivileged content. Set bindToUntrustedContent=true on the binding to override this restriction.

... which is odd because those are meant to have been updated...

Comment 7

[Alice0775 White]

Attachment: debug build log.txt on ubuntu12.04

Comment 8

[:Gijs (he/him)]

I am but a stranger in these parts, but I think the issue is that the Init of a XBL proto binding does this:


  // aElement will be null when reading from the cache, but the element will
  // still be set later.
  if (aElement) {
    SetBindingElement(aElement);
  }
  return NS_OK;


and after several startups, the bindings will be in the XUL cache, and so SetBindingElement is not initially called.

mBindToUntrustedContent defaults to false, and as long as SetBindingElement is not called, it is not updated, so it remains false and is still false when MayBindToContent checks it.

I stuck some printfs in SetBindingElement, and they don't seem to be called against this profile (which has been used and has a cache for this build)

Bobby, does that sound plausible?

Comment 9

[(no longer active)]

(In reply to :Gijs Kruitbosch (intermittently here 14-15 August; then away until 19th) from comment #6)
> These are meant to be regular text input fields on web pages... I'm kind of
> surprised that they would have a XBL binding.

They don't (99.99999% sure.)

Comment 10

[:Gijs (he/him)]

Attachment: Patch

Per IRC. But I'm going to sleep soon, so if this is not right, please steal away.

Comment 11

[:Gijs (he/him)]

remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/0a9a9fe98538

Please merge as appropriate assuming this is green. :-)

Comment 12

[[e-mail]]

(In reply to Ehsan Akhgari from comment #9)
> (In reply to Gijs Kruitbosch from comment #6)
> > These are meant to be regular text input fields on web pages... I'm kind of
> > surprised that they would have a XBL binding.
> 
> They don't (99.99999% sure.)

http://mxr.mozilla.org/mozilla-central/source/layout/style/forms.css#68
http://mxr.mozilla.org/mozilla-central/source/layout/style/forms.css#112

Comment 13

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/0a9a9fe98538

Comment 14

[Ed Morley [:emorley]]

Please could you file a bug to add a test (/fix the current tests)? This was pretty bad but still didn't result in test failures.

Comment 15

[Ed Morley [:emorley]]

Nightly respun.

Comment 18

[:Gijs (he/him)]

(In reply to Ed Morley [:edmorley] from comment #14)
> Please could you file a bug to add a test (/fix the current tests)? This was
> pretty bad but still didn't result in test failures.

This bug depends on the XUL cache and restarting the browser several times. I don't know that there's a sensible way to test for this type of failure in our existing test frameworks... smaug said on IRC that this has happened before, but I don't know if it always manifests in the same way... Olli can you comment as to the feasibility of a test for this kind of thing?

Maybe we'd be better served by a commit hook of sorts? No commits to dom/xbl unless you use the keyword YES_I_TESTED_THE_CACHE? :-)

Comment 19

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

Yes, we've had very similar issues before, and I'm not aware of anyway in our testing infrastructure
how to test this. One would need to restart browser few times using the same profile.

Comment 20

[Ed Morley [:emorley]]

Ok yeah sounds impractical then - thank you though :-)

Comment 21

[alex_mayorga]

I can comment on this bug with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140814005302 CSet: 5299864050ee so I'd say this is fixed.

Thanks!