Last Comment Bug 865374 - Position tabs in the OSX titlebar
: Position tabs in the OSX titlebar
Status: RESOLVED FIXED
:
Product: Firefox
Classification: Client Software
Component: General (show other bugs)
: Trunk
: x86 Mac OS X
: -- normal (vote)
: Firefox 28
Assigned To: Mike Conley (:mconley) - (needinfo me!)
:
:
Mentors:
Depends on: 853415 868211 872636
Blocks: 625989 868107 886317
  Show dependency treegraph
 
Reported: 2013-04-24 11:22 PDT by Mike Conley (:mconley) - (needinfo me!)
Modified: 2014-02-06 02:20 PST (History)
15 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
WIP Patch 1 (12.71 KB, patch)
2013-04-25 16:01 PDT, Mike Conley (:mconley) - (needinfo me!)
no flags Details | Diff | Splinter Review
Addition to WIP v1 patch that adds frameView hooks (10.66 KB, patch)
2013-04-29 16:04 PDT, Steven Michaud [:smichaud] (Retired)
no flags Details | Diff | Splinter Review
Addition to WIP v1 patch that adds frameView hooks, rev1 (11.07 KB, patch)
2013-04-30 08:24 PDT, Steven Michaud [:smichaud] (Retired)
no flags Details | Diff | Splinter Review
Patch v1 (21.56 KB, patch)
2013-04-30 09:39 PDT, Mike Conley (:mconley) - (needinfo me!)
no flags Details | Diff | Splinter Review
Patch v1.1 (20.75 KB, patch)
2013-04-30 09:42 PDT, Mike Conley (:mconley) - (needinfo me!)
no flags Details | Diff | Splinter Review
Patch v1.2 (22.99 KB, patch)
2013-05-01 12:26 PDT, Steven Michaud [:smichaud] (Retired)
no flags Details | Diff | Splinter Review
Patch v1.3 (23.03 KB, patch)
2013-05-01 12:33 PDT, Steven Michaud [:smichaud] (Retired)
b56girard: review+
Details | Diff | Splinter Review
Patch v1.4 (r+'d by bgirard) (22.29 KB, patch)
2013-05-01 14:26 PDT, Mike Conley (:mconley) - (needinfo me!)
no flags Details | Diff | Splinter Review
Patch v1.5 (r+'d by bgirard) (22.42 KB, patch)
2013-05-01 14:34 PDT, Mike Conley (:mconley) - (needinfo me!)
dao+bmo: review-
Details | Diff | Splinter Review
Patch v1.6 (r+'d by bgirard) (21.42 KB, patch)
2013-05-02 08:15 PDT, Mike Conley (:mconley) - (needinfo me!)
no flags Details | Diff | Splinter Review
Patch v1.7 (r+'d by bgirard) (22.92 KB, patch)
2013-05-02 09:10 PDT, Mike Conley (:mconley) - (needinfo me!)
dao+bmo: review+
Details | Diff | Splinter Review
Fix bustage in my part of the patch (3.53 KB, patch)
2013-05-02 16:19 PDT, Steven Michaud [:smichaud] (Retired)
b56girard: review+
Details | Diff | Splinter Review

Description Mike Conley (:mconley) - (needinfo me!) 2013-04-24 11:22:39 PDT
Breaking this out of bug 625989, since that one seems to be mostly concerned with changes to platform and toolkit to support putting the tabs in the titlebar.

This bug will track the patch that will actually put the tabs into the titlebar.

There are three parts to this:

1) Move the tabs into the titlebar
2) Blank out the window title for browser windows
3) Find a way to sample the widths of the window buttons and full screen button, and indent the tabs inwards that amount.
Comment 1 Steven Michaud [:smichaud] (Retired) 2013-04-24 11:30:05 PDT
> 2) Blank out the window title for browser windows

Don't worry about this.  I've already got a way to hook the method that draws the titlebar cell, and can stop it drawing when we need that.

We *don't* want to just blank out a window's title (by setting its title to @"").  That would break external accessibility apps, which examine windows' titles and "speak" them.  This might also break our own accessibility code.
Comment 2 Mike Conley (:mconley) - (needinfo me!) 2013-04-25 16:01:55 PDT
Created attachment 742074 [details] [diff] [review]
WIP Patch 1

This patch alters the OSX CSS to put the tabs back into the titlebar, and adds the CSS hooks that will (hopefully) allow me to sample the widths of the window buttons and full-screen button.
Comment 3 Mike Conley (:mconley) - (needinfo me!) 2013-04-25 16:05:27 PDT
Hey Steven,

So now I've reached the point where I need your help. I've added two CSS values for -moz-appearance:  "-moz-mac-button-box" and "-moz-mac-fullscreen-button".

Right now, I've just hard-coded in the widths returned from nsNativeThemeCocoa.mm. How should I move forward to get the actual widths of the window buttons and the fullscreen button?

The patch *should* apply directly to a recent pull from UX.

Thanks,

-Mike
Comment 4 Steven Michaud [:smichaud] (Retired) 2013-04-25 16:59:00 PDT
I won't have a fix for bug 851652 ready for at least another week.

I could wait until that's finished to replace your hard-coded widths
with actual widths.

Or I could add just enough of it here to measure the actual widths.
For that matter, if you give me a hook to tell me when the window
title should be hidden (not drawn), I could add code for that too.

This would need to be next week (since I have tomorrow off).
Comment 5 Mike Conley (:mconley) - (needinfo me!) 2013-04-26 07:19:33 PDT
(In reply to Steven Michaud from comment #4)
> Or I could add just enough of it here to measure the actual widths.

I think I'd prefer that, if it didn't bit-rot you / slow you down too much.

> For that matter, if you give me a hook to tell me when the window
> title should be hidden (not drawn), I could add code for that too.

I believe the only case where we're drawing in the titlebar is for browser windows - so I believe the value you can look for is the drawsContentsIntoWindowFrame property of the window. Does that give you what you need?

> 
> This would need to be next week (since I have tomorrow off).

Fair enough. Enjoy your day off. :)
Comment 6 Steven Michaud [:smichaud] (Retired) 2013-04-29 08:59:35 PDT
(In reply to comment #5)

I'm just about to start work on this.  I should be able to post something later today.
Comment 7 Steven Michaud [:smichaud] (Retired) 2013-04-29 09:00:17 PDT
The status here should really be NEW :-)
Comment 8 Mike Conley (:mconley) - (needinfo me!) 2013-04-29 11:24:59 PDT
(In reply to Steven Michaud from comment #6)
> (In reply to comment #5)
> 
> I'm just about to start work on this.  I should be able to post something
> later today.

Awesome, thanks!
Comment 9 Steven Michaud [:smichaud] (Retired) 2013-04-29 16:04:44 PDT
Created attachment 743319 [details] [diff] [review]
Addition to WIP v1 patch that adds frameView hooks

Mike:  Here's an addition to your patch that measures titlebar buttons directly and stops the title cell from displaying when we draw in the titlebar.

It works.  For example it still allows the window title to be drawn if we're not drawing in the titlebar (for example in the "Show All Bookmarks" window).

But there's one problem:  Your query from CSS code to find the width of the fullscreen button comes before widget code has has a chance to create it.

One way around this is to use a default value in this case (as my current patch does).  In fact (practically speaking) this may be the best we can do.  But let's keep thinking about it, and we my find a better way.

This patch is meant to be applied to the current UX branch on top of your WIP v1 patch.
Comment 10 Steven Michaud [:smichaud] (Retired) 2013-04-30 08:24:17 PDT
Created attachment 743642 [details] [diff] [review]
Addition to WIP v1 patch that adds frameView hooks, rev1

Cleaned up a bit.
Comment 11 Mike Conley (:mconley) - (needinfo me!) 2013-04-30 09:39:01 PDT
Created attachment 743684 [details] [diff] [review]
Patch v1

Folding our patches together.
Comment 12 Mike Conley (:mconley) - (needinfo me!) 2013-04-30 09:42:55 PDT
Created attachment 743691 [details] [diff] [review]
Patch v1.1

Dao, would you mind reviewing the front-end changes I made?

Benoit - Steven says you're the one to probably review his widget/ changes. Mind taking a peek?

Thanks,

-Mike
Comment 13 Benoit Girard (:BenWa) 2013-05-01 11:30:39 PDT
Comment on attachment 743691 [details] [diff] [review]
Patch v1.1

Review of attachment 743691 [details] [diff] [review]:
-----------------------------------------------------------------

::: gfx/src/nsThemeConstants.h
@@ +245,5 @@
>  #define NS_THEME_WIN_COMMUNICATIONS_TOOLBOX                221
>  #define NS_THEME_WIN_MEDIA_TOOLBOX                         222
>  #define NS_THEME_WIN_BROWSER_TAB_BAR_TOOLBOX               223
>  
> +// Unified toolbar and titlebar elements on the Mac

Do you have someone to review this + the next 2 hunks? I've never seen this code before.

::: widget/cocoa/nsCocoaWindow.mm
@@ +2480,5 @@
> +// know beforehand exactly what the superclasses will be, each of these
> +// classes is created dynamically, using low-level Objective-C runtime
> +// methods.  So their methods' declarations can't use Objective-C syntax.
> +
> +Class gMozTitleCellClass = nil;

static

@@ +2489,5 @@
> +                                       NSView *controlView)
> +{
> +  BaseWindow *window = (BaseWindow *) [controlView window];
> +  if (!window) {
> +    window = (BaseWindow *) [NSView focusView];

I don't understand this line. if controlView is null we will take the focused view? Wont this cause bugs if you have multiple windows?

@@ +2503,5 @@
> +  NSCell_drawWithFrame super = (NSCell_drawWithFrame) objc_msgSendSuper;
> +  super(&target, sel, cellFrame, controlView);
> +}
> +
> +NSMutableDictionary *gFrameViewClassesByStyleMask = nil;

static

@@ +2507,5 @@
> +NSMutableDictionary *gFrameViewClassesByStyleMask = nil;
> +
> +typedef void (*NSFrameView_initTitleCell)(struct objc_super *, SEL, id);
> +
> +static void MozFrameView_initTitleCell(id self, SEL sel, id cell)

I'm not familiar with the code (ClassPair+class_addMethod) and frameViewClassForStyleMask. Trying to see if I can get someone else more knowledge to review this.
Comment 14 Steven Michaud [:smichaud] (Retired) 2013-05-01 11:55:12 PDT
>> +{
>> +  BaseWindow *window = (BaseWindow *) [controlView window];
>> +  if (!window) {
>> +    window = (BaseWindow *) [NSView focusView];
>>
> I don't understand this line. if controlView is null we will take
> the focused view? Wont this cause bugs if you have multiple windows?

This is just syntactic sugar.  I cast the return values of
[controlView window] and [NSView focusView] to BaseWindow* before I
know exactly what's been returned.

But before I use any of those return values, I check (on the next
line) whether or not 'window' is really a BaseWindow*.

Nonetheless you *have* caught me in a mistake, and a pretty bad one:

[NSView focusView] returns an NSView*.  I should have written [[NSView
focusView] window].

>> +Class gMozTitleCellClass = nil;
>
> static

>> +NSMutableDictionary *gFrameViewClassesByStyleMask = nil;
>
> static

I'll fix these.

New patch coming up.
Comment 15 Steven Michaud [:smichaud] (Retired) 2013-05-01 12:00:57 PDT
(Following up comment #14)

The documentation on -[NSCell drawWithFrame:(NSRect)rect inView:(NSView*)view] says that its implementation actually ignores the value of 'view' and instead uses what's returned by [NSView focusView].

My patch is just trying to play safe.  In the very unlikely case that 'view' is nil, it also checks [NSView focusView].
Comment 16 Steven Michaud [:smichaud] (Retired) 2013-05-01 12:09:08 PDT
(Following up comment #15)

I'll add a comment explaining this to my next patch revision.
Comment 17 Steven Michaud [:smichaud] (Retired) 2013-05-01 12:26:25 PDT
Created attachment 744236 [details] [diff] [review]
Patch v1.2

How's this, Benoit?
Comment 18 Steven Michaud [:smichaud] (Retired) 2013-05-01 12:28:23 PDT
Comment on attachment 744236 [details] [diff] [review]
Patch v1.2

Oops, just saw another mistake.  Another patch coming up.
Comment 19 Steven Michaud [:smichaud] (Retired) 2013-05-01 12:33:29 PDT
Created attachment 744237 [details] [diff] [review]
Patch v1.3

How's *this*? :-)
Comment 20 Benoit Girard (:BenWa) 2013-05-01 13:15:06 PDT
Comment on attachment 744237 [details] [diff] [review]
Patch v1.3

Review of attachment 744237 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM
Comment 21 Mike Conley (:mconley) - (needinfo me!) 2013-05-01 14:06:52 PDT
Cool, thanks Benoit.

Steven - who should we ask to review the parts that Benoit wasn't familiar with?
Comment 22 Benoit Girard (:BenWa) 2013-05-01 14:11:20 PDT
(In reply to Mike Conley (:mconley) from comment #21)
> Cool, thanks Benoit.
> 
> Steven - who should we ask to review the parts that Benoit wasn't familiar
> with?

It's probably ok. It looks like internal only defines and list.
Comment 23 Mike Conley (:mconley) - (needinfo me!) 2013-05-01 14:12:09 PDT
Ok, cool, thanks Benoit.
Comment 24 Mike Conley (:mconley) - (needinfo me!) 2013-05-01 14:26:16 PDT
Created attachment 744283 [details] [diff] [review]
Patch v1.4 (r+'d by bgirard)

I realized that I need to set the -moz-box-ordinal-group property on the titlebar-placeholders for Windows and Linux.
Comment 25 Mike Conley (:mconley) - (needinfo me!) 2013-05-01 14:28:09 PDT
Comment on attachment 744283 [details] [diff] [review]
Patch v1.4 (r+'d by bgirard)

Actually, shifting to MattN, who might have some spare cycles to look at this.

Matt - BenWa has already reviewed everything under widget/, so I just need you to check out the changes I made under browser/.
Comment 26 Mike Conley (:mconley) - (needinfo me!) 2013-05-01 14:34:10 PDT
Created attachment 744286 [details] [diff] [review]
Patch v1.5 (r+'d by bgirard)

And I forgot to remove the old ordinal attributes from the appmenu-button titlebar-placeholders.
Comment 27 Matthew N. [:MattN] (In Taipei until Sep. 23) 2013-05-01 21:46:08 PDT
Comment on attachment 744286 [details] [diff] [review]
Patch v1.5 (r+'d by bgirard)

Review of attachment 744286 [details] [diff] [review]:
-----------------------------------------------------------------

Dão: I'm not sure if I'm on the right track with the content/theme distinction and I can't find the DevTools page that helped distinguish the two.

::: browser/base/content/browser.xul
@@ +494,5 @@
>      </hbox>
> +#ifdef XP_MACOSX
> +    <hbox id="titlebar-fullscreen-button-container">
> +      <hbox id="titlebar-fullscreen-button">
> +      </hbox>

Nit: anyone reason this isn't self-closing like the .titlebar-placeholders?

::: browser/themes/linux/browser.css
@@ +38,5 @@
>    border-bottom: 1px solid ThreeDShadow;
>  }
>  
> +.titlebar-placeholder[type="appmenu-button"] {
> +  -moz-box-ordinal-group: 0;

I think this would be better in browser/base/ since it's not specific to the default theme and that's where most of the other -moz-box-ordinal-group properties are in browser.  It might get messy with ifdefs in this case though. What do you think?

::: browser/themes/osx/browser.css
@@ +45,5 @@
> +  -moz-box-ordinal-group: 0;
> +}
> +
> +#titlebar-buttonbox {
> +  -moz-appearance: -moz-mac-button-box;

The added -moz-appearance rules here are just used for sizing IIUC to match the OS controls and so I think these should also be in browser/base/.
Comment 28 Dão Gottwald [:dao] 2013-05-02 05:05:35 PDT
Comment on attachment 744286 [details] [diff] [review]
Patch v1.5 (r+'d by bgirard)

>--- a/browser/base/content/browser.xul
>+++ b/browser/base/content/browser.xul

>     <hbox id="titlebar-buttonbox-container" align="start">
>       <hbox id="titlebar-buttonbox">
>         <toolbarbutton class="titlebar-button" id="titlebar-min" oncommand="window.minimize();"/>
>         <toolbarbutton class="titlebar-button" id="titlebar-max" oncommand="onTitlebarMaxClick();"/>
>         <toolbarbutton class="titlebar-button" id="titlebar-close" command="cmd_closeWindow"/>
>       </hbox>
>     </hbox>
>+#ifdef XP_MACOSX
>+    <hbox id="titlebar-fullscreen-button-container">
>+      <hbox id="titlebar-fullscreen-button">
>+      </hbox>
>+    </hbox>
>+#endif

What's the point of the extra container? titlebar-buttonbox needed a container for align="start", but you didn't use that here.

> #ifdef CAN_DRAW_IN_TITLEBAR
>-      <hbox class="titlebar-placeholder" type="appmenu-button" ordinal="0"/>
>-      <hbox class="titlebar-placeholder" type="caption-buttons" ordinal="1000"/>
>+#ifdef MENUBAR_CAN_AUTOHIDE
>+      <hbox class="titlebar-placeholder" type="appmenu-button"/>
>+#endif
>+      <hbox class="titlebar-placeholder" type="caption-buttons"/>
>+#ifdef XP_MACOSX
>+      <hbox class="titlebar-placeholder" type="fullscreen-button"/>
>+#endif
> #endif

Please use ifdefs for the platform-dependent ordinal values.

>--- a/browser/themes/osx/browser.css
>+++ b/browser/themes/osx/browser.css

>+#titlebar-buttonbox {
>+  -moz-appearance: -moz-mac-button-box;
>+}

Yes, it might make sense to move this to content/browser.css (as -moz-window-button-box; see below).

>+CSS_KEY(-moz-mac-button-box, _moz_mac_button_box)

As far as I can tell, you should just implement -moz-window-button-box on Mac rather than introducing -moz-mac-button-box.
Comment 29 Mike Conley (:mconley) - (needinfo me!) 2013-05-02 08:15:20 PDT
Created attachment 744640 [details] [diff] [review]
Patch v1.6 (r+'d by bgirard)

Moved the ordinal rules back into browser.xul with ifdef's as per Dao's suggestion, and I'm using -moz-window-button-box instead of -moz-mac-button-box.

I also moved the -moz-appearance rules into browser/base/content/browser.css as per Dao / MattN's suggestion.

Tested on Windows, and it seems to do the job. Checkpointing here to test on Linux and OSX, and then I'll request another review.
Comment 30 Dão Gottwald [:dao] 2013-05-02 08:22:14 PDT
Comment on attachment 744640 [details] [diff] [review]
Patch v1.6 (r+'d by bgirard)

>--- a/browser/base/content/browser.css
>+++ b/browser/base/content/browser.css

>+%ifdef XP_MACOSX
>+#titlebar-buttonbox {
>+  -moz-appearance: -moz-window-button-box;
>+}

Can you move this away from the XP_MACOSX ifdef, remove -moz-window-button-box from themes/windows/browser.css and move -moz-window-button-box-maximized here with XP_WIN (or implement -moz-window-button-box-maximized on Mac as an alias for -moz-window-button-box)?
Comment 31 Markus Stange [:mstange] 2013-05-02 09:09:55 PDT
Comment on attachment 744640 [details] [diff] [review]
Patch v1.6 (r+'d by bgirard)

I'd like to review the widget parts of this patch, too.
Comment 32 Mike Conley (:mconley) - (needinfo me!) 2013-05-02 09:10:38 PDT
Created attachment 744662 [details] [diff] [review]
Patch v1.7 (r+'d by bgirard)

(In reply to Dão Gottwald [:dao] from comment #30)
> Comment on attachment 744640 [details] [diff] [review]
> Patch v1.6 (r+'d by bgirard)
> 
> >--- a/browser/base/content/browser.css
> >+++ b/browser/base/content/browser.css
> 
> >+%ifdef XP_MACOSX
> >+#titlebar-buttonbox {
> >+  -moz-appearance: -moz-window-button-box;
> >+}
> 
> Can you move this away from the XP_MACOSX ifdef, remove
> -moz-window-button-box from themes/windows/browser.css and move
> -moz-window-button-box-maximized here with XP_WIN (or implement
> -moz-window-button-box-maximized on Mac as an alias for
> -moz-window-button-box)?

Yep, good plan. I've opted for the former, using the XP_WIN ifdef.

Checkpointing here while I re-test this on Windows.
Comment 33 Mike Conley (:mconley) - (needinfo me!) 2013-05-02 09:16:15 PDT
Comment on attachment 744662 [details] [diff] [review]
Patch v1.7 (r+'d by bgirard)

Ok, this seems to do the job.
Comment 34 Mike Conley (:mconley) - (needinfo me!) 2013-05-02 10:08:19 PDT
Hey Markus,

Thanks for looking at this. Is it possible to have a review done today? We were hoping to land this soon (yesterday, actually).

Thanks,

-Mike
Comment 35 Markus Stange [:mstange] 2013-05-02 10:11:29 PDT
Yes, I'll be done in a few minutes. But the changes I'd like to see don't need to block landing, they can be addressed in a follow-up bug.
Comment 36 Markus Stange [:mstange] 2013-05-02 10:25:32 PDT
Comment on attachment 744662 [details] [diff] [review]
Patch v1.7 (r+'d by bgirard)

Actually, land away. I'll put up a patch with my changes into a new bug and let smichaud review it; I think that will be more effective at this point.
Comment 37 Mike Conley (:mconley) - (needinfo me!) 2013-05-02 10:27:42 PDT
(In reply to Markus Stange from comment #36)
> Comment on attachment 744662 [details] [diff] [review]
> Patch v1.7 (r+'d by bgirard)
> 
> Actually, land away. I'll put up a patch with my changes into a new bug and
> let smichaud review it; I think that will be more effective at this point.

Wonderful, thanks!
Comment 38 Markus Stange [:mstange] 2013-05-02 10:29:18 PDT
By the way, have all the test failures you encountered in bug 625989 comment 54 gone away? In particular I wonder about the crash in test_browserElement_inproc_OpenMixedProcess.html - does that not happen any more? In bug 625989 comment 63 it looked like the current way of drawing in the titlebar just wouldn't work in some cases (maybe just the OMTC case?).
Comment 39 Mike Conley (:mconley) - (needinfo me!) 2013-05-02 10:37:14 PDT
(In reply to Markus Stange from comment #38)
> By the way, have all the test failures you encountered in bug 625989 comment
> 54 gone away? In particular I wonder about the crash in
> test_browserElement_inproc_OpenMixedProcess.html - does that not happen any
> more? In bug 625989 comment 63 it looked like the current way of drawing in
> the titlebar just wouldn't work in some cases (maybe just the OMTC case?).

For better or for worse, it looks like the tack we're taking for Australis is to land, and then deal with test failures after the fact.

I just re-ran the DOM tests, and test_browserElement_inproc_OpenMixedProcess.html does not happen for me. The original test failure in dom/tests/mochitest/chrome/test_selectAtPoint.html now passes.

I am, however, seeing test failures in dom/tests/mochitest/chrome/test_queryCaretRect.html and dom/tests/mochitest/chrome/test_resize_move_windows.xul.

I'll file follow-up bugs for those.
Comment 40 Mike Conley (:mconley) - (needinfo me!) 2013-05-02 11:14:27 PDT
Ah, and it looks like those test failures are actually unrelated to this patch, as they already exist on the Jamun branch.
Comment 41 Mike Conley (:mconley) - (needinfo me!) 2013-05-02 11:16:37 PDT
Landed on the UX branch as https://hg.mozilla.org/projects/ux/rev/c06fb1a7c7fb
Comment 42 Steven Michaud [:smichaud] (Retired) 2013-05-02 15:59:14 PDT
I just discovered that the patches I uploaded here somehow didn't include several of my latest changes.  This could result in problems -- particularly on SnowLeopard, where it will lead to something like a crash (SnowLeopard doesn't have fullscreen buttons).

Sigh :-(

I think I should just post the required changes here, and get them onto the UX branch as soon as possible.  Benoit, I'll ask you once again to review.

Markus, I know you may have problems with my patch.  But let's deal with that later in bug 868211.
Comment 43 Mike Conley (:mconley) - (needinfo me!) 2013-05-02 16:01:41 PDT
(In reply to Steven Michaud from comment #42)
> 
> I think I should just post the required changes here, and get them onto the
> UX branch as soon as possible.

Yes please - before the next UX Nightly spin if possible.
Comment 44 Steven Michaud [:smichaud] (Retired) 2013-05-02 16:19:12 PDT
Created attachment 744892 [details] [diff] [review]
Fix bustage in my part of the patch

Here it is.
Comment 45 Mike Conley (:mconley) - (needinfo me!) 2013-05-02 16:33:22 PDT
Bustage fix landed on UX as https://hg.mozilla.org/projects/ux/rev/401c71c3732d
Comment 46 Morpheus3k 2013-05-05 02:18:37 PDT
Bug 853415 is back again. I assume it is related to draw in the titlebar.
Comment 48 Ioana (away) 2014-02-06 02:20:35 PST
This will be covered by qa in bug 625989.

Note You need to log in before you can comment on or make changes to this bug.