Last Comment Bug 307098 - xbl not created when inside display:none (or hidden=true) element
: xbl not created when inside display:none (or hidden=true) element
Status: RESOLVED WONTFIX
: testcase
Product: Core
Classification: Components
Component: XBL (show other bugs)
: Trunk
: x86 Windows 2000
: -- normal (vote)
: ---
Assigned To: xbl
: Hixie (not reading bugmail)
Mentors:
Depends on:
Blocks: tomtom
  Show dependency treegraph
 
Reported: 2005-09-05 02:35 PDT by Martijn Wargers [:mwargers] (not working for Mozilla)
Modified: 2008-11-26 19:05 PST (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (885 bytes, application/xhtml+xml)
2005-09-05 02:36 PDT, Martijn Wargers [:mwargers] (not working for Mozilla)
no flags Details

Description Martijn Wargers [:mwargers] (not working for Mozilla) 2005-09-05 02:35:03 PDT
See upcoming testcase.
Comment 1 Martijn Wargers [:mwargers] (not working for Mozilla) 2005-09-05 02:36:06 PDT
Created attachment 194897 [details]
testcase
Comment 2 Martijn Wargers [:mwargers] (not working for Mozilla) 2005-09-05 02:43:30 PDT
Hmm, actually this is bug 64234 (which for some reason has become WFM).
Bug 64234, comment 10 says: (bzbarsky)
"We do resolve style for display:none elements (we need to find out they're
display:none!) but not for their descendants...."
Comment 3 Boris Zbarsky [:bz] 2005-09-05 20:29:41 PDT
Yep.  We're not going to support attachment of XBL via style inside display:none
subtrees.
Comment 4 Martijn Wargers [:mwargers] (not working for Mozilla) 2005-09-06 03:31:06 PDT
So that means that CSS is not a reliable way for attaching xbl bindings to a
document, right? I really think this sucks.
I'm also thinking of bug 265086. CSS doesn't apply to nodes outside the
document, right?

The computed style of the element in question says it is bound, by the way. I
don't think that is correct when that's not the case. File a new bug?
Comment 5 Martijn Wargers [:mwargers] (not working for Mozilla) 2005-09-06 04:03:22 PDT
(In reply to comment #4)
> So that means that CSS is not a reliable way for attaching xbl bindings to a
> document, right? I really think this sucks.
Oops, I should not blaim CSS here, right? According to the CSS spec, the binding
should get applied, not?
Comment 6 Boris Zbarsky [:bz] 2005-09-06 09:34:26 PDT
> So that means that CSS is not a reliable way for attaching xbl bindings to a
> document, right?

In Mozilla, yes.  That's why we're working on introducing other binding methods...

> CSS doesn't apply to nodes outside the document, right?

It sorta can be forced to in Mozilla, but in general this is correct.

> The computed style of the element in question says it is bound,

Note that as soon as you access the element from JavaScript the binding _is_
attached.

> According to the CSS spec, the binding should get applied, not?

The CSS spec doesn't say anything about XBL...
Comment 7 Martijn Wargers [:mwargers] (not working for Mozilla) 2005-09-06 16:36:38 PDT
(In reply to comment #6)
> > CSS doesn't apply to nodes outside the document, right?
> It sorta can be forced to in Mozilla, but in general this is correct.

Wouldn't that mean that bug 265086 is invalid, then?

> > The computed style of the element in question says it is bound,
> Note that as soon as you access the element from JavaScript the binding _is_
> attached.
If that was the case, I should get an alert (I have an alert in the
constructor). But I don't get an alert, so I don't think that is the case.
Comment 8 Boris Zbarsky [:bz] 2005-09-06 19:52:02 PDT
> Wouldn't that mean that bug 265086 is invalid, then?

That bug covers the fact that XBL "cannot" be applied to nodes not in a document
even if a binding mechanism other than CSS were used. (I put "cannot" in quotes
because we apply it in some cases, but inconsistently.)

> If that was the case, I should get an alert

The constructor for this "attach because it was touched from JS" scenario is
only run if the binding can be loaded synchronously (i.e. it's already cached or
has a chrome:// URI).  The whole thing is a nasty hack.  :(

Note You need to log in before you can comment on or make changes to this bug.