Closed Bug 282178 Opened 17 years ago Closed 15 years ago

sync xpfe tabbrowser with toolkit tabbrowser

Categories

(Core :: XUL, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: mconnor, Assigned: WeirdAl)

References

Details

Attachments

(3 files, 1 obsolete file)

This will not be fun.
This gets rid of one of the differences.
Attachment #175159 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #175159 - Flags: review?(timeless)
Attachment #175159 - Flags: review?(timeless) → review+
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?
Filter the new tab button as well
Attachment #175159 - Attachment is obsolete: true
Attachment #175489 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #175489 - Flags: review?(timeless)
Attachment #175159 - Flags: superreview?(neil.parkwaycc.co.uk)
Comment on attachment 175489 [details] [diff] [review]
revised double-click filter (checked in)

(19:29:17) <NeilAlmostZZZ> ok, then sr=me
Attachment #175489 - Flags: superreview?(neil.parkwaycc.co.uk) → superreview+
Attachment #175489 - Flags: review?(timeless) → review+
Attachment #175489 - Attachment description: revised double-click filter → revised double-click filter (checked in)
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?
(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).
Status: NEW → ASSIGNED
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.
Attachment #175490 - Flags: review?(mconnor) → review+
(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 on attachment 175490 [details] [diff] [review]
this event listener doesn't need to be capturing (checked in)

checked this in
Attachment #175490 - Attachment description: this event listener doesn't need to be capturing → this event listener doesn't need to be capturing (checked in)
Whiteboard: checkin (2 patches)
Matches change mostly from bug 105885, and other low hanging fruit (event listener change from bug 225854).
Attachment #212443 - Flags: review?(mconnor)
Attachment #212443 - Flags: review?(mconnor) → review+
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
Attachment #212443 - Attachment description: use anonids, <handler> → use anonids, <handler> (checked in)
Bug 323806 in only fixed on the 1.8(.1) branches yet:
so depending on it.
Depends on: 323806
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?
> 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?
(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).
This bug is probably being obsoleted by bug 350221 (creating a suite tabbrowser building upon toolkit browser for use in toolkit-based SeaMonkey versions)
Assignee: cst → ajvincent
Status: ASSIGNED → NEW
per comment 19, wontfix (see bug 350221)
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
No longer blocks: 282177
You need to log in before you can comment on or make changes to this bug.