1709319 - [wayland] Bookmarks popup no longer grows to fit contents

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Emilio Cobos Álvarez [:emilio]]

This is a recent regression. Press Ctrl+D in any page, and when the panel opens click the arrow next to "other bookmarks". The content grows, we make the panel scrollable, but only vertically.

I tried to bisect but it came down to a nonsense commit. However, nightly 2021-04-26 is good, and 2021-04-27 is bad, so the pushlog is:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6f8320a4798f53fa8471efe49181f9d6accead85&tochange=3009bdef939c0786c38c376de07ba615cbca0d8b

The first build between those gets skipped for some reason, so that makes me suspect bug 1707577. Will try to confirm manually.

Comment 1

[Emilio Cobos Álvarez [:emilio]]

Ah, reverting bug 1707209 fixes this.

Comment 2

[Robert Mader [:rmader]]

Interesting - on what backend (Wayland/X11) is that? And does your setup use scaling? The patch should only affect some rounding cases, and even there it should only have changed if scale > 1.

Comment 3

[Emilio Cobos Álvarez [:emilio]]

This only happens with MOZ_ENABLE_WAYLAND=1, and I haven't touched any prefs, this repros on a clean profile. I can attach a recording.

I have a HiDPI screen on Gnome (Fedora 34), with the monitor scale being 2x. What I see is that SetSizeConstraints gets a suitable size, but then the expose event doesn't respect it.

Comment 4

[Emilio Cobos Álvarez [:emilio]]

Attachment: Screencast from 05-04-2021 02:17:20 PM.webm

Comment 5

[Emilio Cobos Álvarez [:emilio]]

Attachment: good.log

Comment 6

[Emilio Cobos Álvarez [:emilio]]

Attachment: bad.log

Comment 7

[Emilio Cobos Álvarez [:emilio]]

bad.log has:

[Parent 266226: Main Thread]: D/Widget nsWindow::ApplySizeConstraints [7f2fa05df800] min size 497 142
[Parent 266226: Main Thread]: D/Widget nsWindow::ApplySizeConstraints [7f2fa05df800] max size 8238 8238
[Parent 266226: Main Thread]: D/Widget nsWindow::OnSizeAllocate [7f2f5b3f8c00] 0,0 -> 351 x 536

good.log has:

[Parent 268947: Main Thread]: D/Widget nsWindow::ApplySizeConstraints [7f16107df800] min size 496 141
[Parent 268947: Main Thread]: D/Widget nsWindow::ApplySizeConstraints [7f16107df800] max size 8238 8238
[Parent 268947: Main Thread]: D/Widget NativeMoveResizeWaylandPopupCallback [7f15ca9e9400] flipped_x 1 flipped_y 0
[Parent 268947: Main Thread]: D/Widget   flipped_rect x=277 y=93 width=349 height=534
[Parent 268947: Main Thread]: D/Widget   final_rect   x=277 y=93 width=349 height=534
[Parent 268947: Main Thread]: D/Widget   orig mBounds x=554 y=186 width=698 height=1068
[Parent 268947: Main Thread]: D/Widget   new mBounds  x=554 y=186 width=698 height=1068 x_parent=0 y_parent=0

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1707209

Comment 9

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1709319 - Fix DevicePixelsToGdkCoordRoundUp and co. r=rmader

The code before was effectively flooring (using integer division).

We can't ceil(), we already add the scale with + scale - 1 to "ceil".
It seems GTK (at least on Wayland) chokes when the pixels are not a
multiplier of the scale factor.

It's not quite rounding up, what these functions do... But anyhow this
restores the pre-existing behavior.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a48bca57476f
Fix DevicePixelsToGdkCoordRoundUp and co. r=rmader

Comment 11

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/a48bca57476f