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

Status: RESOLVED WONTFIX

(Core :: XBL, defect)

Description

[Pete Collins (MDG)]

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.

--pete

Comment 1

[Eric Murphy]

-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.

Comment 2

[Eric Murphy]

I assume the problem lies here:

http://lxr.mozilla.org/seamonkey/source/content/xml/content/src/nsXMLElement.cpp#666

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
nothing.

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("@mozilla.org/xbl;1", &rv);

   if(xblService.BindingReady(this,value...???)
   {
      xblService.FlushStyleBindings(this);
   }
}

Comment 3

[Håkan Waara]

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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

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.

Comment 5

[Jesse Ruderman]

Is this bug about setting -moz-binding to "none" dynamically?  If it is, it's
the same as bug 163023.

Comment 6

[Anne (:annevk)]

Attachment: binding

Comment 7

[Anne (:annevk)]

Attachment: testcase - -moz-binding:none

Comment 8

[Anne (:annevk)]

Attachment: testcase - -moz-binding:url()

Note that although 'url()' does make it disappear it does not reappear after
un-hovering so to say.

Comment 9

[Benjamin Smedberg]

*** Bug 163023 has been marked as a duplicate of this bug. ***

Comment 12

[routehero]

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.

Comment 13

[Jeff Walden [:Waldo]]

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.

Comment 14

[Pete Collins (MDG)]

XUL and XBL are being phased out? What will be used instead for the UI? 

Thanks

Comment 15

[Jeff Walden [:Waldo]]

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.

Comment 16

[Boris Zbarsky [:bzbarsky]]

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.