convert browser-search-autocomplete-result-popup into CE
Categories
(Toolkit :: UI Widgets, task, P2)
Tracking
()
People
(Reporter: surkov, Assigned: surkov)
References
Details
Attachments
(8 files, 5 obsolete files)
16.11 KB,
patch
|
Details | Diff | Splinter Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
Assignee | ||
Comment 1•6 years ago
|
||
Assignee | ||
Updated•6 years ago
|
Updated•6 years ago
|
Assignee | ||
Comment 2•6 years ago
|
||
Assignee | ||
Comment 3•6 years ago
|
||
Emilio, would you please take a look at assertion I get [1], in nsCSSFrameConstructor::ShouldCreateItemsForChild:
Assertion failure: false (asked to create frame construction item for a node that already has a frame), at /builds/worker/workspace/build/src/layout/base/nsCSSFrameConstructor.cpp:5093
It fails for a richlistbox element inside a penel element, which is Custom Element now (was used to be XBL binding).
[1] https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=227752282&repo=try&lineNumber=13557
Comment 4•6 years ago
|
||
Well, the assertion happens here:
(rr) p DumpJSStack()
0 _openAutocompletePopup(aInput = [object XULElement], aElement = [object XULElement]) ["chrome://global/content/elements/autocomplete.js":300:6]
this = [object XULPopupElement]
1 openAutocompletePopup(aInput = [object XULElement], aElement = [object XULElement]) ["chrome://global/content/elements/autocomplete.js":282:4]
this = [object XULPopupElement]
2 openPopup() ["chrome://global/content/bindings/autocomplete.xml":338:12]
this = [object XULElement]
3 set_popupOpen(val = true) ["chrome://global/content/bindings/autocomplete.xml":89:9]
this = [object XULElement]
4 startSearch(aString = "r", aParam = "", aResult = null, aListener = [xpconnect wrapped (nsISupports, nsIAutoCompleteController, nsIAutoCompleteObserver) @ 0x7f1672e63c40 (native @ 0x7f1672e4f500)]) ["chrome://mochitests/content/chrome/toolkit/content/tests/chrome/test_autocomplete2.xul":72:4]
this = [object Object]
From nsXULPopupManager::FirePopupShowingEvent
, which calls into frame construction directly:
The node is the richlistbox, which got its frame on the connectedCallback:
(rr) p DumpJSStack()
0 connectedCallback() ["chrome://global/content/elements/autocomplete.js":92:4]
this = [object XULPopupElement]
1 get_popup() ["chrome://global/content/bindings/autocomplete.xml":79:12]
this = [object XULElement]
2 startTest() ["chrome://mochitests/content/chrome/toolkit/content/tests/chrome/test_autocomplete2.xul":113:5]
this = [object Window]
void
The reason it got a frame is kind of expected:
I guess the way this works with XBL is that it is hitting:
While that's not the case for the dynamic insertion that's happening with the custom element, which goes via InsertFrames.
Comment 5•6 years ago
|
||
It only works basically by chance with XBL and doesn't handle any kind of
dynamic insertion. See comment 4 in the bug for the diagnostic.
Comment 6•6 years ago
|
||
I attached a patch that should fix that. There's a test failure still, but that seems an unrelated issue with your patch.
Updated•6 years ago
|
Assignee | ||
Comment 8•6 years ago
|
||
(In reply to Pulsebot from comment #7)
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/7f9e50bfaad1
Make the XULPopupManager caller to GenerateChildFrames sound. r=mats
huge thanks, Emilio, for fixing it!
Comment 9•6 years ago
|
||
Backed out changeset 7f9e50bfaad1 (bug 1525101) for Mochitest failures in toolkit/content/tests/chrome/test_menulist_paging.xul
Log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=227947255&repo=autoland&lineNumber=18640
Push with failures:
https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=7f9e50bfaad127c642d8537b1a4d4feda283048b
Backout:
https://hg.mozilla.org/integration/autoland/rev/b6f75644ba86d2cc6f4af683a2c45e4f138d02cc
Comment 10•6 years ago
|
||
There is also this bc failure https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=227985450&repo=autoland&lineNumber=1594
Comment 12•6 years ago
|
||
Comment 13•6 years ago
|
||
bugherder |
Assignee | ||
Comment 14•6 years ago
|
||
Assignee | ||
Comment 15•6 years ago
|
||
Assignee | ||
Comment 16•6 years ago
|
||
Assignee | ||
Comment 17•6 years ago
|
||
Assignee | ||
Comment 18•6 years ago
|
||
Assignee | ||
Comment 19•6 years ago
|
||
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Assignee | ||
Comment 20•6 years ago
|
||
Updated•6 years ago
|
Updated•6 years ago
|
Assignee | ||
Comment 21•6 years ago
|
||
Neil, could you take a look at the approach taken for nsIAutoCompletePopup/nsIFormFillController? Does it look reasonable?
Comment 22•6 years ago
|
||
I commented on https://phabricator.services.mozilla.com/D20504
Assignee | ||
Comment 23•6 years ago
|
||
Assignee | ||
Comment 24•6 years ago
|
||
Assignee | ||
Comment 25•6 years ago
|
||
Comment 26•6 years ago
|
||
Comment 27•6 years ago
|
||
bugherder |
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Comment 28•6 years ago
|
||
QA should verify that autocomplete popups in content and the searchbar popup work fine.
Comment 29•6 years ago
|
||
Comment 30•6 years ago
|
||
bugherder |
Assignee | ||
Comment 31•6 years ago
|
||
(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #28)
QA should verify that autocomplete popups in content and the searchbar popup work fine.
I suppose it should be ? request (not +)
Comment 32•6 years ago
|
||
(In reply to alexander :surkov (:asurkov) from comment #31)
(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #28)
QA should verify that autocomplete popups in content and the searchbar popup work fine.
I suppose it should be ? request (not +)
No, that's not how it works… please read the tooltip on the dropdown.
Assignee | ||
Comment 33•6 years ago
|
||
(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #32)
(In reply to alexander :surkov (:asurkov) from comment #31)
(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #28)
QA should verify that autocomplete popups in content and the searchbar popup work fine.
I suppose it should be ? request (not +)
No, that's not how it works… please read the tooltip on the dropdown.
oh, right, sorry, was confused with review request
btw, is there anything left on my side about the last search-popup before review/landing?
Comment 34•6 years ago
|
||
I'm reviewing it now :)
Comment 35•6 years ago
|
||
Comment 36•6 years ago
|
||
bugherder |
Updated•6 years ago
|
Comment 37•6 years ago
|
||
In case it comes up, this broke right-click -> search in new tab for the existing address bar. I'm fixing that in bug 1530961 as I was adding a test there and fixing it for QuantumBar anyway.
Assignee | ||
Comment 38•6 years ago
|
||
(In reply to Mark Banner (:standard8) from comment #37)
In case it comes up, this broke right-click -> search in new tab for the existing address bar. I'm fixing that in bug 1530961 as I was adding a test there and fixing it for QuantumBar anyway.
thank you, I somehow missed that quantum search still has a dependency on autocomplete popup XBL binding.
Comment 39•6 years ago
|
||
(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #28)
QA should verify that autocomplete popups in content and the searchbar popup work fine.
How am I supposed to verify these steps? Steps to reproduce required to verify this bug.
Assignee | ||
Comment 40•6 years ago
|
||
(In reply to Bodea Daniel [:danibodea] from comment #39)
(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #28)
QA should verify that autocomplete popups in content and the searchbar popup work fine.
How am I supposed to verify these steps? Steps to reproduce required to verify this bug.
Matt might be a better person to answer this, but I used [1] to test in content autocomplete popups and searchbar, available from Customize (context menu of Firefox toolbar).
[1] https://luke-chang.github.io/autofill-demo/autocomplete-all.html
Comment 41•6 years ago
|
||
@Matt: Can you help me with some steps to reproduce/verify?
Comment 42•6 years ago
|
||
There are no specific steps since this wasn't a regression fix, it was a refactor. You would have to explore behaviour with autocomplete popups on https://luke-chang.github.io/autofill-demo/autocomplete-all.html for addresses, credit cards, logins, and regular form history (no key icon or grey footer). You should also test the searchbar autocomplete popup. Look for regressions compared to before this change.
Comment 43•6 years ago
|
||
This bug was verified with the feature testing in Fx 67 and second run in Fx 68.
Updated•6 years ago
|
Updated•6 years ago
|
Description
•