1608910 - Bottom buttons disappear when resizing subdialogs

Status: NEW

(Firefox :: Settings UI, defect, P3)

Description

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Attachment: resize remains so buttons get corrupted or disappear.webm

Reproduced in firefox nightly version 74.0a1 (2020-01-13) (64-bit) in Ubuntu 18.04.3 LTS
Build ID 20200113093823

Steps to reproduce:
1- go to about:preferences
2- reach Language and Appearance section
3- click "choose" within language option
4- resize window and close it
5- repeat step 3
6- window size is back to original size before step 4 (attachment: size goes back to original.webm )
7- now go to privacy and security section
8- in Cookies and Site Data section, click Manage Data button
9- Rezise the window (only its widtch no the length)
10- close and repeat step 8
11- resize the window to be smaller, and notice that remove selected/all buttons are cut, and cancel and save changes button are no longer visible. ( attachment resize remains so buttons get corrupted or disappear.webm)

Expected results:
** Buttons should always be visible
** same behaviour should be triggered in every submenu ( there is a max/min size that user can resize, and when resizing window and closing and reopening, size should be the same)
Any of these would work

Actual results:
Buttons are not visible when resizing

Comment 1

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Attachment: size goes back to original.webm

Comment 2

[Clara Guerrero ( Need Info Brindusa Tot Please)]

This is also happening in Beta 73.0b2 (64-bit) and Release 72.0.1 (64-bit), therefore I am updating the flags.

Best,

Clara

Comment 3

[:Gijs (away/busy until Mar 10)]

There are several issues being reported here so now the bug is pretty confusing.

The issue in the summary is that you can resize the "Manage Data" (aka site data settings) dialog so the buttons are cut off.

I cannot reproduce this on 73 beta or nightly on macOS. Is it Ubuntu-specific?

The language dialogs being reset is because they do not persist width/height information, and is unrelated.

Comment 4

[Itiel]

I can also reproduce this, here's a more accurate STR (I think):

1. Open about:preferences#privacy
2. Open "Manage Data"
3. Resize the dialog horizontally in a way that the text above the search box will be in one line
4. Close the dialog
5. Re-open it
6. Resize to the smallest possible size

I'm on Windows 10 btw.

Comment 5

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Hi , I was just able to reproduce this for Mac as well, following the same steps.

Let me know if you need any additional information to replicate it yourself :Gijs

Best,
Clara

Comment 6

[Emilio Cobos Álvarez [:emilio]]

I can repro this on Linux too... Do you know how do we communicate the dialog resize to the inner document? The viewport seems to be off by a bit.

Comment 7

[:Gijs (away/busy until Mar 10)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #6)

I can repro this on Linux too... Do you know how do we communicate the dialog resize to the inner document? The viewport seems to be off by a bit.

I'm unclear what you mean, sorry. What "dialog resize"?

Comment 8

[:Gijs (away/busy until Mar 10)]

(In reply to :Gijs (he/him) from comment #7)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #6)

I can repro this on Linux too... Do you know how do we communicate the dialog resize to the inner document? The viewport seems to be off by a bit.

I'm unclear what you mean, sorry. What "dialog resize"?

Oh, sorry, I came here from the other bug and was confused. I think https://searchfox.org/mozilla-central/rev/803a42f24c8714631ed81cb824ea1c1a803cb7b8/browser/components/preferences/in-content/subdialogs.js#452 is what you're looking for... Otherwise, it's "just" an iframe which will change size based on the containing box, I think?

Comment 9

[Emilio Cobos Álvarez [:emilio]]

So this is some sort of XUL layout bug/quirk with the <browser> element... The browser element's content box (which is what we use to size the inner frame) somehow includes the margins... You can see this by reading getBoundingClientRect() or such.

Comment 10

[:Gijs (away/busy until Mar 10)]

Per comment #9, going to tentatively move this to layout. I don't think we can fix for 72/73 anymore; otherwise I guess prioritization is up to the layout folks.

Comment 11

[Emilio Cobos Álvarez [:emilio]]

Nah, I was wrong...

So what's going on is that this code assumes that the scroll height doesn't change while the dialog is resized... But it does change when the text in the <description> wraps, so the dialog ends up being too small.

This is easily seen when you add manually more text to the <description>, for example. Gijs, how did this use to work in pre-xul, did the <richlistbox> shrink or such?

Comment 12

[Emilio Cobos Álvarez [:emilio]]

I can repro this in 71 too...

Comment 13

[:Gijs (away/busy until Mar 10)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #11)

Nah, I was wrong...

So what's going on is that this code assumes that the scroll height doesn't change while the dialog is resized... But it does change when the text in the <description> wraps, so the dialog ends up being too small.

I'm confused; the assignment to width comes before this, at https://searchfox.org/mozilla-central/rev/803a42f24c8714631ed81cb824ea1c1a803cb7b8/browser/components/preferences/in-content/subdialogs.js#327-334 , so I would have assumed that any wrapping would have happened by the time we ask for scrollHeight. Does asking for scrollHeight not cause a flush?

This is easily seen when you add manually more text to the <description>, for example. Gijs, how did this use to work in pre-xul, did the <richlistbox> shrink or such?

I'm not sure off-hand. It's quite possible this specific set of STR has always been broken.

Comment 14

[Emilio Cobos Álvarez [:emilio]]

scrollHeight does flush but that code doesn't run for every resize.