Closed Bug 963512 Opened 6 years ago Closed 6 years ago

Tabstrip doesn't keep position when in private browsing window.

Categories

(Firefox :: Theme, defect)

29 Branch
All
Windows 7
defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 30
Tracking Status
firefox29 --- fixed
firefox30 --- verified

People

(Reporter: winson.wen1, Assigned: Gijs)

References

Details

(Whiteboard: [Australis:P3][good first verify][testday-20140523])

Attachments

(1 file, 1 obsolete file)

User Agent: Mozilla/5.0 (Android; Tablet; rv:27.0) Gecko/27.0 Firefox/27.0 (Nightly/Aurora)
Build ID: 20140120131346

Steps to reproduce:

Open a private window.
Open enough tabs for tabstrip to be scrollable.
Select a any tab in the middle.
Click outside the window to make it inactive.


Actual results:

Tabstrip scrolls so the active tab is on the right side of the window.


Expected results:

Scroll position in tabstrip stays the same.
OS: Android → Windows 7
Hardware: Other → All
On what version and build ID of Firefox are you seeing this?
Flags: needinfo?(winson.wen1)
(In reply to :Gijs Kruitbosch from comment #1)
> On what version and build ID of Firefox are you seeing this?

where do I find this?
(In reply to winson.wen1 from comment #2)
> (In reply to :Gijs Kruitbosch from comment #1)
> > On what version and build ID of Firefox are you seeing this?
> 
> where do I find this?

Open "about:config" from the address bar, if you see the warning screen, click through it. Type "gecko" in the search box. There should be at least two values in bold: gecko.buildID and gecko.mstone.
(you can right click the rows to copy the value of each)
gecko.buildID;20140122030521 gecko.mstone;29.0a1
Flags: needinfo?(winson.wen1)
Great! Thank you for using nightly and helping us find issues. Some more questions so I can try to reproduce the issue: what windows theme are you using? Aero Glass, non-glass, 'classic', or something else? And, are you using the default font size settings or maybe 110% or 125% or 150%?
Flags: needinfo?(winson.wen1)
Component: Untriaged → Theme
Whiteboard: [Australis:P3]
Matt, Mike, this is reminiscent of bug 853415. :-(
(In reply to :Gijs Kruitbosch from comment #6)
> Great! Thank you for using nightly and helping us find issues. Some more
> questions so I can try to reproduce the issue: what windows theme are you
> using? Aero Glass, non-glass, 'classic', or something else? And, are you
> using the default font size settings or maybe 110% or 125% or 150%?

using aero glass and default font size. also, this I had this bug last year on ux nightly as well.
Flags: needinfo?(winson.wen1)
(In reply to :Gijs Kruitbosch from comment #7)
> Matt, Mike, this is reminiscent of bug 853415. :-(

Yes, this is caused by the ::after element we use for the private browsing icon. Removing the content property there (from within the browser inspector) to remove the box immediately fixes the issue. Sigh.
Blocks: 868640
Status: UNCONFIRMED → NEW
Ever confirmed: true
So the approach we used for other bugs was to position the ::after element as the last element using -moz-ordinal-group styles. Unfortunately that doesn't work here because the position of the element actually matters. While having a real element is perhaps not as 'neat' as a pseudoelement, it does fix this bug and lets us move on with life...
Attachment #8380983 - Flags: review?(dao)
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Comment on attachment 8380983 [details] [diff] [review]
use real element for Australis private browsing indicator to avoid layout issues with detecting ::after

>+#ifdef XP_WIN
>+      <hbox id="private-browsing-indicator" hidden="true" skipintoolbarset="true"
>+            ordinal="1000" />
>+#endif

nit: remove the space before />

>+#main-window[privatebrowsingmode=temporary] #private-browsing-indicator {
>   display: -moz-box;
>   width: 40px;
>   background: url("chrome://browser/skin/privatebrowsing-indicator.png") no-repeat center center;
> }

An empty box shouldn't cause any problems, so you can get rid of hidden="true"/display: -moz-box.

Linux uses #TabsToolbar::before. Is this not a problem?
(In reply to Dão Gottwald [:dao] from comment #11)
> Comment on attachment 8380983 [details] [diff] [review]
> use real element for Australis private browsing indicator to avoid layout
> issues with detecting ::after
> 
> >+#ifdef XP_WIN
> >+      <hbox id="private-browsing-indicator" hidden="true" skipintoolbarset="true"
> >+            ordinal="1000" />
> >+#endif
> 
> nit: remove the space before />
> 
> >+#main-window[privatebrowsingmode=temporary] #private-browsing-indicator {
> >   display: -moz-box;
> >   width: 40px;
> >   background: url("chrome://browser/skin/privatebrowsing-indicator.png") no-repeat center center;
> > }
> 
> An empty box shouldn't cause any problems, so you can get rid of
> hidden="true"/display: -moz-box.
> 
> Linux uses #TabsToolbar::before. Is this not a problem?

I don't think so, as there's no tabs in titlebar and therefore no ordinal-group'd elements that mess with the position of the ::before/::after elements. However, bug 963576 will move those to a 'real' element, too.
Attachment #8380983 - Attachment is obsolete: true
Attachment #8380983 - Flags: review?(dao)
Attachment #8381381 - Flags: review?(dao) → review+
Summary: Tabstrip doesn't keep position when in private browse window. → Tabstrip doesn't keep position when in private browsing window.
remote:   https://hg.mozilla.org/integration/fx-team/rev/faee2530c592
Whiteboard: [Australis:P3] → [Australis:P3][fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/faee2530c592
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Whiteboard: [Australis:P3][fixed-in-fx-team] → [Australis:P3]
Target Milestone: --- → Firefox 30
Comment on attachment 8381381 [details] [diff] [review]
use real element for Australis private browsing indicator to avoid layout issues with detecting ::after

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Australis / bug 868640
User impact if declined: overflown tab strips scroll without user interaction when a private browsing window loses focus
Testing completed (on m-c, etc.): on m-c
Risk to taking this patch (and alternatives if risky): low, moving an element from a pseudo element to a real one
String or IDL/UUID changes made by this patch: none
Attachment #8381381 - Flags: approval-mozilla-aurora?
Attachment #8381381 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Whiteboard: [Australis:P3] → [Australis:P3][good first verify]
Verified as fixed on Windows 7, 64 bits, with Firefox 30 Beta 7 and latest Nightly 32.0a1:

- User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0; Built from: https://hg.mozilla.org/releases/mozilla-beta/rev/f572a9d3afc8

- User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:32.0) Gecko/20100101 Firefox/32.0; Built from: https://hg.mozilla.org/mozilla-central/rev/b40296602083
Status: RESOLVED → VERIFIED
Whiteboard: [Australis:P3][good first verify] → [Australis:P3][good first verify][testday-20140523]
I can also confirm this as verified fixed with latest Fx 30 beta 7 (Build ID: 20140522105902) on Windows 7 x64.
You need to log in before you can comment on or make changes to this bug.