Close buttons on tabs in MultiZilla no longer work

RESOLVED WONTFIX

Status

()

Core
DOM: Events
--
major
RESOLVED WONTFIX
13 years ago
12 years ago

People

(Reporter: HJ, Assigned: roc)

Tracking

({regression, testcase})

Trunk
x86
Windows XP
regression, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

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

Comment 1

13 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.
(Reporter)

Comment 2

13 years ago
Created attachment 212870 [details]
This is the binding used in MultiZilla

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

Comment 3

13 years ago
See also: news://news.mozilla.org:119/bpSdnZSwXaDMP0DenZ2dnUVZ_tadnZ2d@mozilla.org
 and follow ups.
(Reporter)

Comment 4

13 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
Created attachment 212884 [details]
testcase

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.
Keywords: regression, testcase
(Reporter)

Comment 6

13 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?
Flags: blocking1.9a1?
You've got 75000 customers using Multizilla on trunk? ouch!
(Reporter)

Comment 8

13 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 ;)
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.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 10

13 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.
(Reporter)

Comment 11

13 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?
(Reporter)

Comment 12

13 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!?!
(Reporter)

Comment 13

13 years ago
(In reply to comment #12)
s/could/couldn't fix them.
(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.
(Reporter)

Comment 15

13 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!
Flags: blocking1.9a1?
You need to log in before you can comment on or make changes to this bug.