282178 - sync xpfe tabbrowser with toolkit tabbrowser

Status: RESOLVED WONTFIX

(Core :: XUL, defect)

Description

[Mike Connor [:mconnor]]

This will not be fun.

Comment 1

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Attachment: filter double-clicks on tab close button

This gets rid of one of the differences.

Comment 2

[[e-mail]]

Comment on attachment 175159 [details] [diff] [review]
filter double-clicks on tab close button

Do you want this on the new button too, so that when we get the firefox
tabbrowser it won't create extra tabs when you double click it?

Comment 3

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Attachment: revised double-click filter (checked in)

Filter the new tab button as well

Comment 4

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Attachment: this event listener doesn't need to be capturing (checked in)

Get rid of another difference

Comment 5

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Comment on attachment 175489 [details] [diff] [review]
revised double-click filter (checked in)

(19:29:17) <NeilAlmostZZZ> ok, then sr=me

Comment 6

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

checked in attachment 175489 [details] [diff] [review]

Comment 7

[Benjamin Smedberg]

Why can't we just use the toolkit version of this file? Are there significant
differences (i.e. autocomplete widget or somesuch) that are blocking unifying them?

Comment 8

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

(In reply to comment #7)
> Why can't we just use the toolkit version of this file? Are there significant
> differences (i.e. autocomplete widget or somesuch) that are blocking unifying
them?

There are significant differences, but I just tried dropping it in, and
surprisingly enough, the browser isn't completely horked (it worked fine for the
few minutes I tested).  However, for the sake of code quality / safety, I'd
still rather do a merge (this also gives us another chance to justify each
change and make sure things make sense).

Comment 9

[Mike Connor [:mconnor]]

Comment on attachment 175490 [details] [diff] [review]
this event listener doesn't need to be capturing (checked in)

r=me, conditional on tracking down the bugs referenced in blake's checkin that
changed these, and ensuring that this doesn't somehow regress it.

Comment 10

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

(In reply to comment #9)
> (From update of attachment 175490 [details] [diff] [review] [edit])
> r=me, conditional on tracking down the bugs referenced in blake's checkin that
> changed these, and ensuring that this doesn't somehow regress it.
> 
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=AviaryBranchTinderbox&branch=AVIARY_1_0_20040515_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-07-26+20%3A00&maxdate=2004-07-26+20%3A25&cvsroot=%2Fcvsroot
Bug, singular :)

Comment 11

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

(In reply to comment #10)
> (In reply to comment #9)
> > (From update of attachment 175490 [details] [diff] [review] [edit] [edit])
> > r=me, conditional on tracking down the bugs referenced in blake's checkin that
> > changed these, and ensuring that this doesn't somehow regress it.
> > 
>
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=AviaryBranchTinderbox&branch=AVIARY_1_0_20040515_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-07-26+20%3A00&maxdate=2004-07-26+20%3A25&cvsroot=%2Fcvsroot
> Bug, singular :)

Oh.  Wrong checkin.  Bugs, plural, and no, they (bug 232770, bug 227887) don't
seem to regress.

Comment 12

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Comment on attachment 175490 [details] [diff] [review]
this event listener doesn't need to be capturing (checked in)

checked this in

Comment 13

[:Gavin Sharp [email: [e-mail]]]

Attachment: use anonids, <handler> (checked in)

Matches change mostly from bug 105885, and other low hanging fruit (event listener change from bug 225854).

Comment 14

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 212443 [details] [diff] [review]
use anonids, <handler> (checked in)

mozilla/toolkit/content/widgets/tabbrowser.xml 	1.103.2.28
mozilla/toolkit/content/widgets/tabbrowser.xml 	1.136

Comment 15

[Serge Gautherie (:sgautherie)]

Bug 323806 in only fixed on the 1.8(.1) branches yet:
so depending on it.

Comment 16

[Robert Kaiser]

We should probably fork xpfe tabbrowser.xml into suite/ for use in toolkit-based SeaMonkey (see also bug 282179) and sync it with toolkit/Firefox tabbrowser only as far as we find it useful, we probably don't want to go all the way there.

Who can work on this? CTho?

Comment 17

[Eyal Rozenberg]

> we probably don't want to go all the way there.

Why? If there's code there that's strictly ff-specific, shouldn't it be out of the toolkit and in browser/ somehow?

Comment 18

[Robert Kaiser]

(In reply to comment #17)
> > we probably don't want to go all the way there.
> 
> Why? If there's code there that's strictly ff-specific, shouldn't it be out of
> the toolkit and in browser/ somehow?

Actually, the tabbrowser.xml is completely Firefox-specific, tabbrowser is not seen as a toolkit feature, and yes, it's planned to move it to browser/ in the Firefox3 cycle, but it just hasn't been done yet (as the Firefox team is still focusing more on FF2 than FF3).

Comment 19

[Robert Kaiser]

This bug is probably being obsoleted by bug 350221 (creating a suite tabbrowser building upon toolkit browser for use in toolkit-based SeaMonkey versions)

Comment 20

[Alex Vincent [:WeirdAl]]

per comment 19, wontfix (see bug 350221)