Close tabs and exit window modal is cut off is browser is resized to minimum height and trying to close the browser
Categories
(Toolkit Graveyard :: Notifications and Alerts, defect, P2)
Tracking
(firefox-esr78 unaffected, firefox86 wontfix, firefox87 wontfix, firefox88 wontfix, firefox89 wontfix, firefox90 fixed)
People
(Reporter: atrif, Assigned: Gijs)
References
(Blocks 2 open bugs, Regressed 1 open bug)
Details
(Keywords: helpwanted, regression, Whiteboard: [proton-modals] [priority:2a])
Attachments
(8 files)
Affected versions
- 88.0a1 (20210317212527)
Affected platforms
- macOS 11.2.2
- Windows 10x64
- Ubuntu 20
Steps to reproduce
- Open Firefox and a few tabs
- Resize Firefox horizontally to the minimum height.
- 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.
Reporter | ||
Comment 1•4 years ago
|
||
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Comment 2•4 years ago
•
|
||
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.
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 3•4 years ago
|
||
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.
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 4•3 years ago
|
||
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.
Assignee | ||
Comment 5•3 years ago
|
||
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.
Comment 6•3 years ago
|
||
Assignee | ||
Comment 7•3 years ago
|
||
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
Comment 9•3 years ago
|
||
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
Comment 10•3 years ago
|
||
Assignee | ||
Comment 11•3 years ago
|
||
(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.
Comment 12•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/8c020ab6a68f
https://hg.mozilla.org/mozilla-central/rev/0216a43087e0
Comment 13•3 years ago
|
||
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.
Assignee | ||
Comment 14•3 years ago
|
||
(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 setstatus_beta
towontfix
.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.
Reporter | ||
Comment 15•3 years ago
•
|
||
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!
Assignee | ||
Comment 16•3 years ago
|
||
(In reply to Alexandru Trif, QA [:atrif] from comment #15)
Created attachment 9221116 [details]
Screenshot 2021-05-10 at 15.27.53.pngHello! 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...
Reporter | ||
Comment 17•3 years ago
|
||
(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.pngHello! 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.
Reporter | ||
Comment 18•3 years ago
|
||
Assignee | ||
Comment 19•3 years ago
|
||
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?
Reporter | ||
Comment 20•3 years ago
•
|
||
(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.
Assignee | ||
Comment 21•3 years ago
|
||
(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.
Updated•3 years ago
|
Comment 22•3 years ago
|
||
Hi Gijs, is this one https://bugzilla.mozilla.org/show_bug.cgi?id=1710462 a duplicate?
Best,
Clara
Assignee | ||
Comment 23•3 years ago
|
||
(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.
Updated•3 years ago
|
Updated•1 year ago
|
Description
•