Closed
Bug 475327
Opened 16 years ago
Closed 16 years ago
[Linux] New Tab button is still right side of the Tab bar
Categories
(Firefox :: Tabbed Browser, defect, P2)
Tracking
()
VERIFIED
FIXED
Firefox 3.6a1
People
(Reporter: hidenosuke, Assigned: dao)
References
Details
(Keywords: verified1.9.1)
Attachments
(2 files)
52.97 KB,
image/png
|
Details | |
9.11 KB,
patch
|
Gavin
:
review+
|
Details | Diff | Splinter Review |
Bug 457651 has been fixed but New Tab button is still right side of
the Tab bar with Linux build.
Please see the screenshot.
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•16 years ago
|
||
Looks like we're getting a flawed overflow event from the arrowscrollbox.
Version: unspecified → 3.1 Branch
Comment 3•16 years ago
|
||
I only see this using the default theme. Other themes show with it at the end of the tab list.
Updated•16 years ago
|
Flags: blocking-firefox3.1?
Comment 4•16 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•16 years ago
|
||
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 | ||
Comment 6•16 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.
Reporter | ||
Comment 7•16 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.
Updated•16 years ago
|
Flags: blocking-firefox3.1? → blocking-firefox3.1+
Priority: -- → P2
Comment 8•16 years ago
|
||
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?
Comment 10•16 years ago
|
||
So that means that it is fixed without this patch? Or am I the only one?
Assignee | ||
Comment 11•16 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).
Comment 12•16 years ago
|
||
Oh, I'm sorry.
But it occurs also when I use a new profile and then use the normal one.
Comment 13•16 years ago
|
||
You can download my build (just finished compiling) at http://mozilla.webdesign-portal.net .. Looks like the patch works!
Comment 14•16 years ago
|
||
Sometimes it works for me without this patch.. But only sometimes and I couldn't figure out why it does that..
Comment 15•16 years ago
|
||
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+
Updated•16 years ago
|
Whiteboard: [needs review gavin]
Assignee | ||
Comment 16•16 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•16 years ago
|
Keywords: checkin-needed
Assignee | ||
Comment 17•16 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/89fb0fa39e0b
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/97d4c788dee0
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Keywords: checkin-needed → fixed1.9.1
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.2a1
Comment 18•16 years ago
|
||
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
Comment 19•15 years ago
|
||
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.
Description
•