User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

sway version 1.4 (Wayland)

1. Open Firefox on a non hidpi monitor (e.g. an external monitor). Laptop screen is currently disabled

2. Disconnect external monitor and re-enable inbuild hidpi monitor

Actual results:

Firefox is scaled to the wrong size. It chooses a scale which is too large for it (which is strange as in the past it was too small instead). I've included a screenshot showing how this looks

running journalctl -e shows a large number of the following error

gdk_monitor_get_scale_factor: assertion 'GDK_IS_MONITOR (monitor)' failed

Expected results:

Firefox should have adjusted its scale correctly for the hidpi monitor.

This used to work in previous firefox versions

Yes, it's known bug with WebRender enabled. Can you confirm it happens only when WebRender is enabled or do you see that with SW render too?

Just confirmed that it only happens when WebRender is enabled

I've just noticed that new (or closed and then restored) windows are drawn correctly. (Which, if nothing else, allows for working around this without rebooting the entire session).

Happens also when layers.acceleration.force-enabled is set to true.

Works fine when both accel and webrender are turned off.

Should this bug block "wayland" and "wr-linux" (I can't edit the bug myself)?

This is a regression, it worked fine in FF71 with webrender or layers accel or both enabled.

(In reply to luis.pabon from comment #7)

This is a regression, it worked fine in FF71 with webrender or layers accel or both enabled.

If anyone could run mozregression to find when it broke (you can run it with --prefs gfx.webrender.all:true) then it'd be quite amazing.

Done.

> env MOZ_ENABLE_WAYLAND=1 mozregression --good 2019-08-26 --pref gfx.webrender.all:true

[...]
 6:20.84 INFO: No more integration revisions, bisection finished.
 6:20.84 INFO: Last good revision: d6709b4ccf48e8efa8a6efcd478f97c7ee4e2d48
 6:20.84 INFO: First bad revision: f389488df7cc2bf33d7d44393f2d18a501aaef76
 6:20.84 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d6709b4ccf48e8efa8a6efcd478f97c7ee4e2d48&tochange=f389488df7cc2bf33d7d44393f2d18a501aaef76

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d6709b4ccf48e8efa8a6efcd478f97c7ee4e2d48&tochange=f389488df7cc2bf33d7d44393f2d18a501aaef76

• f389488 Bug 1592933 - [Wayland] Cache scale factor for toplevel windows, r=jhorak
• 8e5e094 Bug 1592933 - [Wayland] Get scale factor from nsWindow::GdkScaleFactor() and set it when wl_surface/egl_window is used for rendering, r=jhorak

Bug 1592933 seems to me like a pretty clear winner here.

Same symptoms as old bug https://bugzilla.mozilla.org/show_bug.cgi?id=1528581 which was fixed sometime prior to this regression.

Rather, old fixed bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1507989 (the other is dup)

I think this is the same as bug 1607745

So, to make cache work for us we just need to not move windows from the display they were open on. If a new window is needed, make sure to have cursor on the proper display before firing shortcut.

I took a look at the code. The issue seems to be that nothing in OnScaleChanged calls wl_surface_set_buffer_scale. The code for that was removed in Bug 1592933 and it's not clear to me what the replacement is supposed to be since I'm not familiar at all with the code.

The attached patch fixes it for me (Arch Linux, sway 1.4 and sway master). It calls wl_surface_set_buffer_scale right from OnScaleChanged. Again, someone more knowledgeable with the code will probably know what's the cleaner/right fix.

Thanks, I'll check it.

• Integrate scale factor setup to moz_container_get_wl_surface() and don't call it explicitly.
• No need to set it explicitly at nsWindow::GetWaylandSurface().
• Update client offset when scale changes in CSD mode by UpdateClientOffsetFromCSDWindow().
• Update scale factor/opaque region on EGL immediately.

Depends on D68351

try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=ba679db57659c3ab6e7bc532513285bfc46e283b

Thanks Dario, I used your patch as a base for the two above.

Just tested a build with the latest patches, and it works great!

Thanks a lot Martin!

I'm glad to hear so :)

https://hg.mozilla.org/mozilla-central/rev/22fa6cbe3298
https://hg.mozilla.org/mozilla-central/rev/b651ff8263af

Thank you folks 👍