1586816 - Double or half sized image flashes for a split second when dragging Firefox between displays with different DPI

Status: REOPENED

(Core :: Widget, defect, P2)

Description

[tbodt]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

I have a MacBook Pro with Retina display and an attached non-Retina external display. To reproduce, drag a window from one display to the other.

Actual results:

The browser content renders in the wrong DPI for a split second before re-rendering in the right DPI.

Expected results:

It should always render in the right DPI.

This sounds similar to https://bugzilla.mozilla.org/show_bug.cgi?id=962528, but it's happening on latest Nightly (71.0a1).

Comment 1

[Seba S.]

Hi, tblodt!

Thanks for your contribution!

I could reproduce the described behavior in:

macOS Mojave v10.14.6
Firefox Nightly 71.0a1 (2019-10-11) (64-bit)
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0

As you mentioned, when switching from Pro Retina to non-Retina external display there's a quick re-size or re-fetch of the window and content.

I've tested this with the NY times web and as far as I could see the text and banners response really quick, in both ways, passing from retina to non-retina and backward, but in terms of streaming platforms such as YouTube or Twitch, the re-size of the modal where the video is playing takes a little bit more to re-size (Not longer than a second).

Also, when moving the browser window from non-retina to the MacBook, the window doesn't get re-sized automatically, but I assume this is a macOS issue since neither firefox, chrome, or safari do it as default. So, in order to fetch the window to the MacBook, you need to double click on the window header.

I've added a product and component so the devs can continue working and researching on this.

Regards,

Comment 2

[Stephen A Pohl [:spohl]]

Thanks. This is a duplicate of bug 962528.

Comment 3

[Florian Quèze [:florian]]

(In reply to Stephen A Pohl [:spohl] from comment #2)

Thanks. This is a duplicate of bug 962528.

I don't think so. The patch I landed in that bug only fixed the problem in the parent process for the chrome UI. This bug is about the browser content, ie. things from the content processes.

Comment 4

[tbodt]

This is definitely not a of bug 962528 since that bug is closed. This bug is present on Nightly.

Comment 5

[Stephen A Pohl [:spohl]]

(In reply to Florian Quèze [:florian] from comment #3)

(In reply to Stephen A Pohl [:spohl] from comment #2)

Thanks. This is a duplicate of bug 962528.

I don't think so. The patch I landed in that bug only fixed the problem in the parent process for the chrome UI. This bug is about the browser content, ie. things from the content processes.

My mistake. I went off an old list that still listed bug 962528 as unresolved. On the other hand, bug 962528 was originally reported against scaling issues in content as well. We shall use this bug to track the content side.

Comment 7

[Jonathan Kew [:jfkthame]]

Although this is a longstanding issue, it sounds (from bug 1657886) like it may get worse/more noticeable in macOS 11.0, unfortunately.

Comment 9

[Florian Quèze [:florian]]

Here's a profile of dragging a browser window with about:newtab back and forth between 2 external monitors (of likely different DPI). https://share.firefox.dev/3sK5DnY Screenshots show clearly when something looks wrong on screen. Looking at the runnables in the content process, I see we have multiple PBrowser::Msg_UpdateDimensions causing restyles.

Comment 10

[Florian Quèze [:florian]]

I just got another profile of this today (https://share.firefox.dev/31zKp0m) and it's not just in the content process that there are things that don't look right. We repaint incorrect things 3 times before we do the final correct paint, and during some of that time the chrome is also at an incorrect size.

Comment 11

[Emilio Cobos Álvarez (:emilio)]

This isn't really macOS specific.

Comment 12

[Xaver Hugl]

Can confirm on Wayland, moving from a 135% scaled screen to a 100% scaled screen almost always shows at least one frame with wrongly scaled content. With a website that's slow to update, like Element Web, it's very noticeable.