Show origin to tabmodal alert/confirm/prompt dialogs
Categories
(Firefox :: General, enhancement)
Tracking
()
Tracking | Status | |
---|---|---|
firefox86 | --- | fixed |
People
(Reporter: Gijs, Assigned: mtigley)
References
(Blocks 1 open bug)
Details
(Whiteboard: [proton-modals])
Attachments
(1 file)
We should display the origin inside the dialog.
Updated•4 years ago
|
Assignee | ||
Comment 1•4 years ago
|
||
This looks like it will be fixed by Bug 1680637 once it lands.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 2•4 years ago
•
|
||
(In reply to Micah Tigley [:mtigley] from comment #1)
This looks like it will be fixed by Bug 1680637 once it lands.
The origin text appears on macos, but not on Windows so we'll need to continue investigating this
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 3•4 years ago
|
||
Updated•4 years ago
|
Comment 5•4 years ago
|
||
Backed out changeset 8ef2ff6e404d (bug 1682393) for mochitest failures at test_modal_prompts.html and bc failures on browser_tabdialogbox_content_prompts.js.
https://hg.mozilla.org/integration/autoland/rev/a00e9283fb2da0f43720f833b1cb3dce10837235
Failure log:
https://treeherder.mozilla.org/logviewer?job_id=327077295&repo=autoland&lineNumber=2317
https://treeherder.mozilla.org/logviewer?job_id=327077752&repo=autoland&lineNumber=2248
Assignee | ||
Comment 6•4 years ago
|
||
The change we introduced in https://phabricator.services.mozilla.com/D102077 will also show the origin title for the old modals and tests in tab_modal_prompts.html are catching this.
Since showing the title is specifically for the new modal dialogs, I think we should add a check for the prompts. contentPromptSubDialog
when we hide #infoTitle.
Comment 8•4 years ago
|
||
Backed out changeset cc07576670e7 (bug 1682393) for Browser-chrome in browser/base/content/test/tabdialogs/browser_tabdialogbox_content_prompts.js. CLOSED TREE
Log:
https://treeherder.mozilla.org/logviewer?job_id=327213927&repo=autoland&lineNumber=2245
Push with failures:
https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&revision=cc07576670e7a2760307defb0712d59300cf8254
Backout:
https://hg.mozilla.org/integration/autoland/rev/905f911db2dd2b0f748a89d3a99500828e2715b1
Assignee | ||
Comment 9•4 years ago
|
||
(In reply to Dorel Luca [:dluca] from comment #8)
Backed out changeset cc07576670e7 (bug 1682393) for Browser-chrome in browser/base/content/test/tabdialogs/browser_tabdialogbox_content_prompts.js. CLOSED TREE
That's odd, a push to tryserver I made earlier didn't seem to catch this on Linux: https://treeherder.mozilla.org/jobs?repo=try&revision=34c8fc6fcc7cc6d7b22196a48c4e33cb4724224a . I'll investigate tomorrow.
Reporter | ||
Comment 10•4 years ago
|
||
(In reply to Micah Tigley [:mtigley] from comment #9)
(In reply to Dorel Luca [:dluca] from comment #8)
Backed out changeset cc07576670e7 (bug 1682393) for Browser-chrome in browser/base/content/test/tabdialogs/browser_tabdialogbox_content_prompts.js. CLOSED TREE
That's odd, a push to tryserver I made earlier didn't seem to catch this on Linux: https://treeherder.mozilla.org/jobs?repo=try&revision=34c8fc6fcc7cc6d7b22196a48c4e33cb4724224a . I'll investigate tomorrow.
Looks like it's failing only on tsan
, which wasn't in your trypush. In all the time I've worked fulltime on Mozilla stuff, this is the first tsan-only failure caused by a frontend patch that I've seen, so don't lose any sleep over it. It's pretty odd... given that this isn't really a low-level/C++ change.
Failure message:
TEST-UNEXPECTED-FAIL | browser/base/content/test/tabdialogs/browser_tabdialogbox_content_prompts.js | Uncaught exception - at chrome://mochitests/content/browser/browser/base/content/test/tabdialogs/browser_tabdialogbox_content_prompts.js:62 - TypeError: can't access property "_dialogReady", dialog is undefined
I'm guessing there's some kind of race condition - tsan builds are slow. I'm guessing using:
let dialogShown = BrowserTestUtils.waitForEvent(gBrowser, "DOMWillOpenModalDialog");
before creating the tab, and then
await dialogShown
before running let dialog = contentPromptManager._dialogs[0];
would fix this. This isn't hitting the previous test because it opens the dialog directly/synchronously from within the parent process.
Comment 11•4 years ago
|
||
Comment 12•4 years ago
|
||
bugherder |
Comment 13•4 years ago
|
||
Updated•4 years ago
|
Description
•