[Linux] New Tab button is still right side of the Tab bar

VERIFIED FIXED in Firefox 3.6a1

Status

()

Firefox
Tabbed Browser
P2
normal
VERIFIED FIXED
8 years ago
8 years ago

People

(Reporter: Hideo Oshima, Assigned: dao)

Tracking

({verified1.9.1})

3.5 Branch
Firefox 3.6a1
x86
Linux
verified1.9.1
Points:
---
Bug Flags:
blocking-firefox3.5 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

8 years ago
Created attachment 358822 [details]
Screnshot of Tab bar

Bug 457651 has been fixed but New Tab button is still right side of
the Tab bar with Linux build.

Please see the screenshot.
Blocks: 457651

Comment 1

8 years ago
The same (New Tab button on left) on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090125 Minefield/3.2a1pre
(Assignee)

Comment 2

8 years ago
Looks like we're getting a flawed overflow event from the arrowscrollbox.
Version: unspecified → 3.1 Branch
(Assignee)

Updated

8 years ago
Depends on: 288395

Comment 3

8 years ago
I only see this using the default theme. Other themes show with it at the end of the tab list.

Updated

8 years ago
Flags: blocking-firefox3.1?

Comment 4

8 years ago
I was playing around with the styles on os x and accidentally changed the margin-bottom of the tabs. This seems to have caused this same bug, so it's overflowing vertically and thinking it should show the right-aligned new tab button.
(Assignee)

Comment 5

8 years ago
Created attachment 358879 [details] [diff] [review]
patch

Yeah, we need to check the overflow direction.
I think it's also time to clean up the handling of these events a bit.
Assignee: nobody → dao
Status: NEW → ASSIGNED
Attachment #358879 - Flags: review?(gavin.sharp)
(Assignee)

Comment 6

8 years ago
Comment on attachment 358879 [details] [diff] [review]
patch

>diff --git a/toolkit/content/widgets/scrollbox.xml b/toolkit/content/widgets/scrollbox.xml

>-      <handler event="underflow"><![CDATA[
>+      <handler event="underflow" phase="capturing"><![CDATA[

>-      <handler event="overflow"><![CDATA[
>+      <handler event="overflow" phase="capturing"><![CDATA[

Note that these handlers need to run before those in tabbrowser.xml, hence this change.
(Assignee)

Updated

8 years ago
No longer depends on: 288395
(Reporter)

Comment 7

8 years ago
(In reply to comment #5)
> Created an attachment (id=358879) [details]
> patch
> 
> Yeah, we need to check the overflow direction.
> I think it's also time to clean up the handling of these events a bit.

I tried the patch.
It looks good for me.
Thanks.
Flags: blocking-firefox3.1? → blocking-firefox3.1+
Priority: -- → P2
Works for me in Ubuntu 8.10 with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090129 Minefield/3.2a1pre ID:20090129020428 ...

The patch isn't implemented yet, is it?
(Assignee)

Comment 9

8 years ago
No, it isn't.
Whiteboard: [needs review gavin]
So that means that it is fixed without this patch? Or am I the only one?
(Assignee)

Comment 11

8 years ago
To reproduce this bug, you need to use the default theme and open a window where the tab bar doesn't overflow immediately (that is, without restoring a session with lots of tabs).
Oh, I'm sorry.

But it occurs also when I use a new profile and then use the normal one.
You can download my build (just finished compiling) at http://mozilla.webdesign-portal.net .. Looks like the patch works!
Sometimes it works for me without this patch.. But only sometimes and I couldn't figure out why it does that..
Comment on attachment 358879 [details] [diff] [review]
patch

(In reply to comment #6)
> Note that these handlers need to run before those in tabbrowser.xml, hence this
> change.

Why? r=me with that explained.
Attachment #358879 - Flags: review?(gavin.sharp) → review+
Whiteboard: [needs review gavin]
(Assignee)

Comment 16

8 years ago
(In reply to comment #15)
> (From update of attachment 358879 [details] [diff] [review])
> (In reply to comment #6)
> > Note that these handlers need to run before those in tabbrowser.xml, hence this
> > change.
> 
> Why? r=me with that explained.

Because this.scrollBoxObject.ensureElementIsVisible(tabs.selectedItem); needs to run after the scroll buttons are shown, otherwise the selected tab won't be fully visible. This means that the underflow handler in scrollbox.xml doesn't need to change, but I figured it's better to make both cases consistent.
(Assignee)

Updated

8 years ago
Keywords: checkin-needed
(Assignee)

Comment 17

8 years ago
http://hg.mozilla.org/mozilla-central/rev/89fb0fa39e0b
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/97d4c788dee0
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Keywords: checkin-needed → fixed1.9.1
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.2a1
Verified on the 1.9.1 branch using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090213 Shiretoko/3.1b3pre.
Keywords: fixed1.9.1 → verified1.9.1
Verified fixed with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2b3pre) Gecko/20091111 Namoroka/3.6b3pre ID:20091111033750
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.