Affected versions

• 88.0a1 (20210317212527)

Affected platforms

• macOS 11.2.2
• Windows 10x64
• Ubuntu 20

Steps to reproduce

1. Open Firefox and a few tabs
2. Resize Firefox horizontally to the minimum height.
3. Click the X button and make the Firefox window bigger.

Expected result

• Close tabs modal is displayed as expected.

Actual result

• Close tabs modal is cut off.

Regression range

• I will search for one ASAP if there is one.

Notes

• Attached a screen recording.

Adding the manual regression range made on Windows 10x64:
Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6f7e9ff0c23e3844b46ca31481027d5c29040638&tochange=6c32d769ff9a1ad140d62f94dc4f7af97fa3f696

The issue is reproducible with the implementation of the Close tabs and exit window only.

The logic in gDialogBox at https://searchfox.org/mozilla-central/rev/368607c4cd5be547021945e4ae60e8eb4365b3c4/browser/base/content/browser.js#9543,9548 forces the dialog to be below the toolbox (minus a few pixels) which doesn't fit well when the window is this small. In fact, the easiest way to address this might actually be to use CSS in browser.css and a media query that overrides that margin-top value with !important, and instead sets it to some small arbitrary offset like 10px so it's not quite right at the top of the window.

Per discussion with Ed and Emanuela, we're going to try at least using more of the toolbar space when the window is not tall enough. I'll take a look at this.

There are a few disparate changes in this commit that combine to fix the bug.
In no particular order:

• set a min-height on windows with toolbars. This extends the minimum
  content size from toolbarless windows to ones with toolbars, on the
  assumption that the overhead from the toolbar and tabs is always
  going to be at least 25px, even in compact mode (it's significantly
  more at the moment). This is also conveniently just enough for
  dialogs with a title, body and checkbox, at the default OS font size,
  to be usable (though the bottom can still get a little cut-off).
• stop assuming there's 30px frame overhead on top of the size of the
  browser in which the dialog is displayed in SubDialog.jsm. This is
  perhaps true in prefs where we display a titlebar outside of the
  browser, but we don't do this for content/tab/window-modal dialogs
  shown in browser.xhtml so the code shouldn't assume. Without this,
  when the window starts off not being tall enough to fit, we were
  losing an additional 30px for no reason.
• instead of subtracting the 1em padding on the <dialog> that the
  default styling provides (https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/layout/style/res/html.css#815 ) just reset it to 0 and stop subtracting it.
• remove the CSS rule for tab and window-modal dialogs that depends on
  --doc-height-px. It is never set, because it is only set for the
  limitheight sizeto value in SubDialog.jsm, and the only
  consumer that sets that is at
  https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/browser/base/content/browser.js#8988
  for content dialogs.
• set the margin-top for the window-modal-dialog element from CSS
  instead of from the gDialogBox code in browser.css (now without the 1em
  subtraction, see above).
• expose the height of the dialog to the parent of the dialog overlay
  from SubDialog.jsm as --inner-height
• use CSS to ensure the dialog is off-set to be just below chrome
  when its size allows this, and otherwise move it up until it
  fits. There's a code comment explaining this.

This is based on feedback from Ed in https://phabricator.services.mozilla.com/D114292#3711919,

One case that does behave inconsistently is that edit bookmark can become tall with tags open and directly updates the browser height

Indeed, moving this to use 'resizeBy', and setting the --inner-height property
that is used by the previous commit (D114292) to position window-modal dialogs
when we lack vertical space, elegantly solves this issue.

Depends on D114292

Backed out 2 changesets (bug 1699430) for WPT Failures in /html/semantics/embedded-content/the-img-element/image-loading-lazy-base-url.html. CLOSED TREE

Log:
https://treeherder.mozilla.org/logviewer?job_id=339062672&repo=autoland&lineNumber=9033

Push with failres:
https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&revision=7f44fe2ccd4f593d4c0d599389a522be4e3a0ab0

Backout:
https://hg.mozilla.org/integration/autoland/rev/3a1d8d62f0dc6e6cb68a4e6126031de50e98d146

(In reply to Dorel Luca [:dluca] from comment #9)

Backed out 2 changesets (bug 1699430) for WPT Failures in /html/semantics/embedded-content/the-img-element/image-loading-lazy-base-url.html. CLOSED TREE

For the avoidance of doubt, this was due to another patch that landed around the same time, so the patch was relanded.

https://hg.mozilla.org/mozilla-central/rev/8c020ab6a68f
https://hg.mozilla.org/mozilla-central/rev/0216a43087e0

The patch landed in nightly and beta is affected.
:Gijs, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #13)

The patch landed in nightly and beta is affected.
:Gijs, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Shilpa, can you confirm whether product wants to uplift this change? From an engineering perspective, I think the change is upliftable assuming we get QA verification.

Hello! Unfortunately, I can still reproduce the issue with 90.0a1 (20210510093555)on Ubuntu 20.04 by following the str from comment 0. I can reproduce it as well on Windows 10x64 and macOS if Title Bar is activated but not without. Also, on macOS 11.3.1 the browser controls will get over the modal when the browser has minimum width and height. Is this expected? Thank you!

(In reply to Alexandru Trif, QA [:atrif] from comment #15)

Created attachment 9221116 [details]
Screenshot 2021-05-10 at 15.27.53.png

Hello! Unfortunately, I can still reproduce the issue with 90.0a1 (20210510093555)on Ubuntu 20.04 by following the str from comment 0. I can reproduce it as well on Windows 10x64 and macOS if Title Bar is activated but not without.

Can you attach a screenshot from Ubuntu? TBH, I don't think we'll be making more changes to try to avoid this. In the screenshot you posted, about 30px of the webpage is visible. Nobody really makes their window that small - the internet itself is not usable like that. Also, in the same screenshot, the dialog is completely readable and the buttons can be clicked (even if the dialog is cut off at the bottom), so the severity is not really the same. We could potentially try to enforce a minimum height on the main browser, but that is a separate discussion.

Also, on macOS 11.3.1 the browser controls will get over the modal when the browser has minimum width and height. Is this expected? Thank you!

It's probably not ideal. You could file a separate bug for this, but I don't know that it'll be very high priority...

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

(In reply to Alexandru Trif, QA [:atrif] from comment #15)

Created attachment 9221116 [details]
Screenshot 2021-05-10 at 15.27.53.png

Hello! Unfortunately, I can still reproduce the issue with 90.0a1 (20210510093555)on Ubuntu 20.04 by following the str from comment 0. I can reproduce it as well on Windows 10x64 and macOS if Title Bar is activated but not without.

Can you attach a screenshot from Ubuntu? TBH, I don't think we'll be making more changes to try to avoid this. In the screenshot you posted, about 30px of the webpage is visible. Nobody really makes their window that small - the internet itself is not usable like that. Also, in the same screenshot, the dialog is completely readable and the buttons can be clicked (even if the dialog is cut off at the bottom), so the severity is not really the same. We could potentially try to enforce a minimum height on the main browser, but that is a separate discussion.

Yes ofc. Attaching 2 screenshots.

Also, on macOS 11.3.1 the browser controls will get over the modal when the browser has minimum width and height. Is this expected? Thank you!

It's probably not ideal. You could file a separate bug for this, but I don't know that it'll be very high priority...

Thank you! I will and add it hereafter.

Hm, attachment 9221125 [details] is very surprising to me. Can you elaborate on the steps to reproduce? It is surprising both that the dialog is cut off and that there is so much space both above and below the dialog. Did you change the size of the window after the dialog appeared?

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

Hm, attachment 9221125 [details] is very surprising to me. Can you elaborate on the steps to reproduce? It is surprising both that the dialog is cut off and that there is so much space both above and below the dialog. Did you change the size of the window after the dialog appeared?

Yes, I changed the size to show that the modal stays like this after the browser was shrunk to minimum height and width. Sorry for not saying that in the first place.

(In reply to Alexandru Trif, QA [:atrif] from comment #20)

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

Hm, attachment 9221125 [details] is very surprising to me. Can you elaborate on the steps to reproduce? It is surprising both that the dialog is cut off and that there is so much space both above and below the dialog. Did you change the size of the window after the dialog appeared?

Yes, I changed the size to show that the modal stays like this after the browser was shrunk to minimum height and width. Sorry for not saying that in the first place.

OK, thanks for the quick clarification. This does seem like it can still be improved further. I've filed bug 1710462 for this.

Hi Gijs, is this one https://bugzilla.mozilla.org/show_bug.cgi?id=1710462 a duplicate?
Best,
Clara

(In reply to Clara Guerrero from comment #22)

Hi Gijs, is this one https://bugzilla.mozilla.org/show_bug.cgi?id=1710462 a duplicate?
Best,
Clara

Not quite - this bug made it so that dialogs are able to fit in smaller windows than before. That bug is to ensure that if the dialog does not initially fit well, if the user makes the window bigger, the dialog does not stay tiny, but becomes bigger so that it becomes usable in that larger window.