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•5 years ago
|
| Assignee | ||
Comment 1•5 years ago
|
||
This looks like it will be fixed by Bug 1680637 once it lands.
| Assignee | ||
Updated•5 years ago
|
| Assignee | ||
Comment 2•5 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•5 years ago
|
| Assignee | ||
Updated•5 years ago
|
| Assignee | ||
Comment 3•5 years ago
|
||
Updated•5 years ago
|
Comment 5•5 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•5 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•5 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•5 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•5 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•5 years ago
|
||
Comment 12•5 years ago
|
||
| bugherder | ||
Comment 13•5 years ago
|
||
Updated•5 years ago
|
Description
•