Closed Bug 119078 Opened 23 years ago Closed 8 years ago

-moz-binding: none; doesn't remove a binding


(Core :: XBL, defect)

Not set





(Reporter: pete, Unassigned)


(Blocks 1 open bug)


(Keywords: testcase)


(3 files)

Here you go Dave.

If you want to tell me where this code lives, i'll take a stab at it for you if
you want.

Target Milestone: --- → mozilla0.9.9
-moz-binding:url(""); has done the trick for me, Pete. One of the examples in
the chapter I wrote uses this... but this would be better anyway.
I assume the problem lies here:

Looks like nothing was implemented for the no value case 'none', and see if
there is something already attached. If there is, then unattach it, otherwise do

Here is some dumb psuedo-code:

if (!value.IsEmpty()) {
// Assuming -moz-binding:none will get us here
else {
 // Move this out of the if statement would be better (along with the other one) 
    nsCOMPtr<nsIXBLService> xblService = 
        do_GetService(";1", &rv);

Target Milestone: mozilla0.9.9 → mozilla1.2
Eric, I very much doubt it because:

1) it is inside GetScriptObject() (<script/> support is not yet implemented)
2) the fact that the code is #ifdef 0-ed out.
testcase please?  "-moz-binding: none" and "-moz-binding: url('')" should do
_exactly_ the same thing as far as I can tell.  If one does not work, neither
should the other, and conversely.

Is this bug about setting -moz-binding to "none" dynamically?  If it is, it's
the same as bug 163023.
Blocks: 57805
Attached file binding
Note that although 'url()' does make it disappear it does not reappear after
un-hovering so to say.
Assignee: hyatt → general
OS: FreeBSD → All
QA Contact: jrgmorrison → ian
Hardware: PC → All
Target Milestone: mozilla1.2alpha → ---
Keywords: testcase
*** Bug 163023 has been marked as a duplicate of this bug. ***
Depends on: 51262
Blocks: 170341
Blocks: 409051
Assignee: xbl → nobody
QA Contact: ian → xbl
What's the plan for this?

A website that has a style with -moz-binding set on an element is not able to specify on the element's style attribute a different value.

Firefox's Inspect -> Computed style indicates the value on the element's style attribute is the "Best Match" but still does not respect it.
XBL is disabled in content, so websites can't use XBL bindings, so these days this is utterly irrelevant to any website.

As for a plan, I suspect at this point there is none, and given XUL/XBL are slowly being phased out, this might as well be WONTFIX.
XUL and XBL are being phased out? What will be used instead for the UI? 

I'd mostly expect HTML plus CSS, using various new things like CSS flexbox and grids for layout, Web Components in place of XBL, and so on.  And extensions would be working with a more structured API like Web Extensions, than with the do-anything-you-want model of classic extensions.

There would still be APIs to access privileged functionality.  But I'd expect them largely to be JavaScript-based, with extra-privileges features hidden behind the function abstraction barrier.  Just like APIs like Geolocation, device access, etc. exposed to the web are.

But to be clear, "phased out" is more a sense-of-the-times claim, than describing an active, concerted effort.  There's not a timeline on this, an announcement, etc.  It's just that in the modern world with far more powerful web standards, Mozilla-proprietary stuff has much less value, making it a significantly harder sell to developers.  And I don't think our single-vendor, unspecified APIs are all that much different from those of any other browser -- they're things we'd prefer to replace with standard things, for the benefit of the open web.
OK, since I seem to own XBL now... officially marking wontfix.  I'm not aware of anyone planning to work on this, though a patch that fixed it without adding too much complexity would probably be accepted.  Note that I'm not aware of a way to do this without adding too much complexity, not least because the concept of "remove a binding" is not very well defined at all.
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.