Erratic tab rendering on external display of retina Mac

RESOLVED FIXED in Firefox 42

Status

()

defect
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: rfeeley, Assigned: mattwoodrow)

Tracking

({regression})

42 Branch
mozilla42
x86
macOS
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox42 fixed)

Details

(Whiteboard: [STR in comment 8])

Attachments

(3 attachments)

Reporter

Description

4 years ago
Posted image nightly-tab-bug.png
See attached. After I resized my window and dragged it around, it went away, but was happening for over an hour after reconnecting to my non-retina monitor.
Have you been able to replicate this at all or was it a one-off?
Reporter

Comment 2

4 years ago
One-off
Reporter

Comment 3

4 years ago
Posted image nightly-tab-bug2.png
Second one just in case
Can you try to recall the exact steps you went through in order to get into this state?

You had a Firefox window on your Retina Macbook display... you plugged it into a secondary non-Retina monitor... did the window automatically move to the non-Retina display, or did you drag it there?
Flags: needinfo?(rfeeley)
Reporter

Comment 5

4 years ago
Typically I use the external display when at my desk. When I go to a meeting I unplug and all windows move to the retina. This happened after I came back. I didn't do anything different than usual, but haven't reproduced it yet. I expect I will at some point when in Nightly (had to switch to release as I was having other problems).
Flags: needinfo?(rfeeley)
Comment hidden (obsolete)
Note that my STR worked perfectly with a fresh profile on 10.8.5.
Whiteboard: [STR in comment 6]
STR:

1) Start with Retina Macbook plugged into secondary standard DPI display.
2) Start Nightly, and put it on the Retina display.
3) Unplug the display.
5) Quickly open and close a window in Nightly. Now open a new tab. If it seems garbled - congratulations, you've seen the bug. If not, go to the next step.
6) Plug the display back in, and put Nightly on the standard DPI display. Now open a new tab.

Behold some hilarious rendering action.
Whiteboard: [STR in comment 6] → [STR in comment 8]
Anything in that range look particularly suspicious?
Flags: needinfo?(jmuizelaar)
Yes:
https://hg.mozilla.org/integration/mozilla-inbound/rev/3a266383e726 is suspicious.

If you could be back that one out and try again that would be wonderful.
Flags: needinfo?(jmuizelaar)
(In reply to Jeff Muizelaar [:jrmuizel] from comment #11)
> Yes:
> https://hg.mozilla.org/integration/mozilla-inbound/rev/3a266383e726 is
> suspicious.
> 
> If you could be back that one out and try again that would be wonderful.

Yes - I can't reproduce with that changeset backed out.
Blocks: 1188995
Flags: needinfo?(matt.woodrow)
Keywords: regression
Can we back out bug 1188995 until this gets resolved? The UX when the user gets into this state is the bad kind of spectacular.
Flags: needinfo?(jmuizelaar)
Assignee

Comment 14

4 years ago
I'll fix this today.
Flags: needinfo?(matt.woodrow)
Cool, thanks. Happy to verify.
Flags: needinfo?(jmuizelaar)
Assignee

Comment 16

4 years ago
Assignee: nobody → matt.woodrow
Attachment #8645047 - Flags: review?(bgirard)
Comment on attachment 8645047 [details] [diff] [review]
compute-tile-size-once

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

::: gfx/thebes/gfxPlatform.cpp
@@ +1003,5 @@
>  {
>    // The tile size should be picked in the parent processes
>    // and sent to the child processes over IPDL GetTileSize.
>    if (!XRE_IsParentProcess()) {
> +    return;

.... meeehhh ... ok fine :)

We've got good asserts covering the tile size getting set properly anyways.

::: gfx/thebes/gfxPlatform.h
@@ +755,5 @@
>      virtual void GetPlatformCMSOutputProfile(void *&mem, size_t &size);
>  
> +    /**
> +     * Calling this function will compute and set the ideal tile size for the
> +     * platform. This should only be called in the parent process; child processes

This comment could use an update.
Attachment #8645047 - Flags: review?(bgirard) → review+
I cannot reproduce the bug with this patch applied. Great job!
https://hg.mozilla.org/mozilla-central/rev/daef3729bce2
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
You need to log in before you can comment on or make changes to this bug.