HJ Reporter
	Description • 19 years ago

Close buttons on tabs in MultiZilla no longer work (after almost five years) in SeaMonkey nightlies after 2006012409 (maybe a day later)

	HJ Reporter
	Comment 1 • 19 years ago

What I did for MultiZilla like five years ago is adding close buttons to close individual tabs be extending the tab binding, but onclick is no longer triggered and you can test it like this:

-<xul:image class="tab-icon" xbl:inherits="validate,src=image"/>
+<xul:image class="tab-icon" xbl:inherits="validate,src=image" onclick="dump('\nimage.onclick\n');"/> 

and note that the dump won't show up anymore.

	HJ Reporter
	Comment 2 • 19 years ago

Note: I wrote this five years ago, so please let me know if I should change anything.  Thanks.

	HJ Reporter
	Comment 3 • 19 years ago

See also: news://news.mozilla.org:119/bpSdnZSwXaDMP0DenZ2dnUVZ_tadnZ2d@mozilla.org
 and follow ups.

	HJ Reporter
	Comment 4 • 19 years ago

(In reply to comment #1)
>
> -<xul:image class="tab-icon" xbl:inherits="validate,src=image"/>
> +<xul:image class="tab-icon" xbl:inherits="validate,src=image"
> onclick="dump('\nimage.onclick\n');"/> 

That line is: 
http://lxr.mozilla.org/mozilla/source/xpfe/global/resources/content/bindings/tabbox.xml#489

	Martijn Wargers (dead)
	Comment 5 • 19 years ago

Minimal testcase that I could come up with, based on Multizilla.
The <xul:deck> tag is necessary to make the alert work on Mozilla builds prior to the frame display lists patch, but my feeling is that the alert also should work when there is no <xul:deck> tag.

	HJ Reporter
	Comment 6 • 19 years ago

Robert, have you seen this? Are you working on it?

For your info: we have over 75000 customers who are hit by this bug every single day, so can you please at least confirm this bug?

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 7 • 19 years ago

You've got 75000 customers using Multizilla on trunk? ouch!

	HJ Reporter
	Comment 8 • 19 years ago

(In reply to comment #7)
> You've got 75000 customers using Multizilla on trunk? ouch!

Yes, I uploaded the wrong SeaMonkey installer to my employers server, but I wasn't aware of it until people started to complain about this bug, and that was after 74312 downloads ;)

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 9 • 19 years ago

Okay, I have figured out what's going on. Basically, the old behaviour was wrong and the new behaviour is right.

As Martijn indicated in comment #5, we do not normally allow events to target the children of XUL buttons. (Ditto for HTML buttons, but that's different code.) Adding the deck in there basically triggered a buggy behaviour because the event went directly to the deck's view, bypassing the button frame.

We could change XUL button behaviour but that seems undesirable unless a strong case can be made ... and for consistency we'd want to change HTML buttons at the same time, and I'm not sure that can be done in a Web-compatible way. If you want to go this way, please file a new bug *and* include a complete rationale and specification for what you want to happen.

You should be able to correct this by not making the tab be based on a XUL button. You might want to try putting a button child under the closebox.

	HJ Reporter
	Comment 10 • 19 years ago

(In reply to comment #9)
> As Martijn indicated in comment #5, we do not normally allow events to target
> the children of XUL buttons.

To me 'nomally' is when people use a 'feature' for very long time. Also, the next version of Mozilla Firefox will have a close button as button child so I'm either reading this wrong or it isn't clear to me what you mean with this.

> We could change XUL button behaviour but that seems undesirable unless a strong
> case can be made ... 

So many people using a 'feature' for over five years isn't a strong case? 

> You should be able to correct this by not making the tab be based on a XUL
> button. You might want to try putting a button child under the closebox.

I can try to make a workaround, but I'm sure that it will introduce other bugs in either MultiZilla or Mozilla code.

	HJ Reporter
	Comment 11 • 19 years ago

"As Martijn indicated in comment #5, we do not normally allow events to target
the children of XUL buttons."

Since when is a tab a button?

	HJ Reporter
	Comment 12 • 19 years ago

I woke up in the middle of the night, at te wrong side of the ocean so I panicked a little, because I have had similar XML problems in the past and I could fix them.

Now, replacing that XUL image with a XUL button didn't work, obviously, but then I had my first coffee and suddenly realized what you said: "we do not normally allow events to target the children of XUL _buttons_"  so the answer was to use display="xul:box" instead.

You're not going to change this I hope!?!

	HJ Reporter
	Comment 13 • 19 years ago

(In reply to comment #12)
s/could/couldn't fix them.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 14 • 19 years ago

(In reply to comment #10)
> (In reply to comment #9)
> > We could change XUL button behaviour but that seems undesirable unless a
> > strong case can be made ... 
> 
> So many people using a 'feature' for over five years isn't a strong case?

Yes, if that feature is just a bug that creates a gross inconsistency in the platform.

(In reply to comment #11)
> Since when is a tab a button?

Since the tab XBL binding inherited from "xul:button".

(In reply to comment #12)
> Now, replacing that XUL image with a XUL button didn't work, obviously, but
> then I had my first coffee and suddenly realized what you said: "we do not
> normally allow events to target the children of XUL _buttons_"  so the answer
> was to use display="xul:box" instead.
> 
> You're not going to change this I hope!?!

I'm not sure what you mean, but if you mean you've changed your tab binding to use "xul:box", then you should be OK.

	HJ Reporter
	Comment 15 • 19 years ago

(In reply to comment #14)
> I'm not sure what you mean, but if you mean you've changed your tab binding to
> use "xul:box", then you should be OK.

Yes, that is what I did after waking up properly.

Thank you for your time Robert!