Closed
Bug 1823187
Opened 2 years ago
Closed 2 years ago
Sometimes searchbar popup is mispositioned (with lots of engines?)
Categories
(Core :: XUL, defect)
Tracking
()
RESOLVED
FIXED
113 Branch
| Tracking | Status | |
|---|---|---|
| firefox-esr102 | --- | unaffected |
| firefox111 | --- | unaffected |
| firefox112 | --- | unaffected |
| firefox113 | --- | fixed |
People
(Reporter: emilio, Assigned: emilio)
References
(Regression)
Details
(Keywords: nightly-community, regression)
Attachments
(1 file)
See bug 1823144 comment 0, bug 1823144 comment 4 and bug 1823144 comment 5.
I haven't been able to repro this yet.
|
Assignee | |
Comment 1•2 years ago
|
||
After bug 1809084, the popup positioning code became more sound,
including reliably positioning once after opening.
This code was asynchronously reducing the size of the popup, sometimes
after popup positioning.
Which means that if the popup had to slide (due to having many one-off
buttons), and we then shrunk it, the popup would be mispositioned.
There's no reason the getBoundsWithoutFlushing call has to be async
afaict, so just size the popup up-front.
|
||
Comment 2•2 years ago
|
||
Set release status flags based on info from the regressing bug 1809084
status-firefox111:
--- → unaffected
status-firefox112:
--- → unaffected
status-firefox113:
--- → affected
status-firefox-esr102:
--- → unaffected
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4c91a04207a6
Don't asynchronously size searchbar popup. r=mak
|
||
Comment 4•2 years ago
|
||
| bugherder | ||
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 113 Branch
You need to log in
before you can comment on or make changes to this bug.
Description
•