The window of a detached tab is larger than the original
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr128 | --- | unaffected |
firefox135 | --- | unaffected |
firefox136 | --- | unaffected |
firefox137 | --- | fixed |
People
(Reporter: tgnff242, Assigned: emilio)
References
(Regression)
Details
(Keywords: nightly-community, regression)
Attachments
(2 files)
Steps to reproduce:
- Open a window with two tabs.
- Drag one of the tabs and create a new window.
This was tested on KDE/X11.
Actual results:
The new window ends up being larger than the original.
Expected results:
Regressed by 581863.
Comment 1•2 months ago
|
||
:emilio, since you are the author of the regressor, bug 581863, could you take a look? Also, could you set the severity field?
For more information, please visit BugBot documentation.
![]() |
||
Updated•2 months ago
|
Assignee | ||
Comment 2•2 months ago
|
||
Let Gecko choose a suitable size. This seems to result in the desired
behavior (same as Ctrl+N). Tested GNOME and Kwin, X11 and Wayland.
The reason for the behavior change here is because outerWidth
before
the regressing patch returned the inner, not the outer width. Combined
with the pre-existing behavior that decorations are added asynchronously
by the window manager, it just happened to conveniently cancel out that
bug, which is now fixed.
It's unclear we need this at all on macOS fwiw. IIRC Cmd+N does also the
same thing as Windows, so maybe we can remove this block altogether.
Separate patch tho, as I don't have a macOS build ready to test it this
very moment, but I think it should just work.
Updated•2 months ago
|
Assignee | ||
Comment 3•2 months ago
|
||
Just tested, doesn't change behavior.
Assignee | ||
Updated•2 months ago
|
Comment 6•2 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/dbbe4e0b455e
https://hg.mozilla.org/mozilla-central/rev/4eb870204239
Description
•