Closed
Bug 1473819
Opened 6 years ago
Closed 6 years ago
Autocomplete popup isn't resized properly
Categories
(DevTools :: Console, defect, P1)
DevTools
Console
Tracking
(firefox-esr52 unaffected, firefox-esr60 unaffected, firefox61 unaffected, firefox62 unaffected, firefox63 verified)
VERIFIED
FIXED
Firefox 63
Tracking | Status | |
---|---|---|
firefox-esr52 | --- | unaffected |
firefox-esr60 | --- | unaffected |
firefox61 | --- | unaffected |
firefox62 | --- | unaffected |
firefox63 | --- | verified |
People
(Reporter: nchevobbe, Assigned: jdescottes)
References
Details
(Keywords: regression)
Attachments
(2 files)
**Steps to reproduce**
1. Open the console
2. In the input, type `document.` and wait for the autocompletion popup to be displayed
3. hit `<kbd>q</kbd>`
**Expected results**
The popup is filtered with methods starting with q, and its height is adjusted to the number of items it contains.
**Actual results**
The popup is filtered with methods starting with q, but the height stays the same, giving the popup an awkward look (See attachment).
Reporter | ||
Comment 1•6 years ago
|
||
mozregression points to Bug 1461522.
Brian, would you know what is happening here ?
Depends on: 1461522
Flags: needinfo?(bbirtles)
Keywords: regression
Priority: -- → P1
Target Milestone: --- → Firefox 63
Version: unspecified → Trunk
Assignee | ||
Comment 2•6 years ago
|
||
This regression comes from a change to the default value of the "height" option of HTMLTooltip.show(). "height" is now "auto" by default. It measures the content height when you show the tooltip and uses this height to create the container. Before that the default height option was "Infinity", which is creating an auto-expanding container. I think we can simply force the autocomplete-popup to force "height: Infinity" to fix this for now.
Note, we could also leverage the new updateContainerBounds() method which should allow to resize the tooltip, but maybe in a second step.
Comment hidden (mozreview-request) |
Reporter | ||
Comment 4•6 years ago
|
||
mozreview-review |
Comment on attachment 8990220 [details]
Bug 1473819 - Force height: Infinity for HTMLTooltip used by autocomplete;
https://reviewboard.mozilla.org/r/255252/#review262142
Works like a charm. Thanks Julian !
Attachment #8990220 -
Flags: review?(nchevobbe) → review+
Reporter | ||
Comment 5•6 years ago
|
||
> Note, we could also leverage the new updateContainerBounds() method which should allow to resize the tooltip, but maybe in a second step.
Sounds good. I'm curious, is there any cost using the Infinity height ?
Flags: needinfo?(bbirtles)
Assignee | ||
Comment 6•6 years ago
|
||
(In reply to Nicolas Chevobbe [:nchevobbe] from comment #5)
> > Note, we could also leverage the new updateContainerBounds() method which should allow to resize the tooltip, but maybe in a second step.
>
> Sounds good. I'm curious, is there any cost using the Infinity height ?
There are nasty side-effects when using the XUL wrapper :( Technically the tooltip creates a container element which takes the whole height of the viewport. With the pure HTMLTooltip, this works fine, we can make the container transparent and forward events, so the user really doesn't notice it. But with the XUL wrapper, we haven't found a solution to forward events to the background. So, as long as the tooltip is displayed, all the area above and below the tooltip can't be used (no clicks, no mouseover etc...)
For the autocomplete-popup, we are not using the XUL wrapper, so we can safely use height: Infinity.
Pushed by jdescottes@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b57224f76cd2
Force height: Infinity for HTMLTooltip used by autocomplete;r=nchevobbe
Comment 8•6 years ago
|
||
bugherder |
Updated•6 years ago
|
Assignee: nobody → jdescottes
Updated•6 years ago
|
Blocks: 1461522
status-firefox61:
--- → unaffected
status-firefox62:
--- → unaffected
status-firefox-esr52:
--- → unaffected
status-firefox-esr60:
--- → unaffected
No longer depends on: 1461522
Updated•6 years ago
|
Flags: qe-verify+
Comment 9•6 years ago
|
||
Managed to reproduce the issue on 63.0a1 (2018-07-04).
Have checked with 64.0a1 (2018-09-20), 63.0b7 on win10x64, macOS 10.13.6, Ubuntu 16.04LTS and can confirm that the issue is no longer reproducible.
You need to log in
before you can comment on or make changes to this bug.
Description
•