Closed Bug 1686315 Opened 4 years ago Closed 4 years ago

Adapt modal tests so that they work with Proton modals enabled or disabled

Categories

(Toolkit Graveyard :: Notifications and Alerts, defect, P1)

Tracking

(firefox89 fixed)

RESOLVED FIXED
89 Branch
Tracking Status
firefox89 --- fixed

People

(Reporter: mtigley, Assigned: mconley)

References

(Blocks 1 open bug)

Details

(Keywords: helpwanted, Whiteboard: [proton-modals])

Attachments

(4 files)

The new tab modal UI used for content prompts should also test the behavior expected of the old modal UI.

Assignee: nobody → mtigley
Status: NEW → ASSIGNED
Whiteboard: [proton-modals]
See Also: → 1686741
Depends on: 1686743
Severity: -- → S4
Priority: -- → P2

As per guidance from Vicky, for tracking, we're marking all the bugs that people are working on as P1.

Priority: P2 → P1

The Bugbug bot thinks this bug should belong to the 'Toolkit::Notifications and Alerts' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: General → Notifications and Alerts
Product: Firefox → Toolkit

I've created a spreadsheet tracking the bugs that are failing for content prompts opened with TabDialogBox.

Keywords: helpwanted

Marking as P2. Per experience review we agreed to mark as P1 bugs only bugs that will block MR1.

Priority: P1 → P2

Re-marking as P1, because tests will start failing when we flip the pref, so this is really blocking…

Priority: P2 → P1

Stealing, per agreement with mtigley.

Assignee: mtigley → mconley
Summary: Introduce tests for new modal UI alongside the old ones → Adapt modal tests so that they work with Proton modals enabled or disabled
See Also: → 1702059

Notably absent from these two batches are fixes for:

  • browser/components/extensions/test/browser/browser_ext_optionsPage_modals.js (covered by bug 1702059)
  • accessible/tests/mochitest/relations/test_ui_modalprompt.html

The test_ui_modalprompt.html test failure is unclear to me, and I'm consulting with morgan who's dealing with similar issues in bug 1700735 and bug 1699053. I don't know if fixing that test should block MR1, but if it doesn't, I can spin out a new bug for it.

See Also: → 1700735, 1699053

From morgan in Matrix:

so it looks like one of the changes that pref causes is our dialog elements are now in internal frames in the a11y tree. I think those frames might be eating the events that we're waiting for in that test (we get a show for the frame, but not the dialog). not sure what needs to be changed there just yet, but sounds like we'll have to modify how we handle events for dialogs. I'll keep ya updated if I find a solution

We might want to file a follow-up bug for test_ui_modalprompt.html, unless fixing it as an accessibility blocker for MR1.

Asa, putting this on your radar in case this needs to be factored into MR1, accessibility-wise.

Flags: needinfo?(asa)

The patches here have approval to land, but they cause a shutdown window leak in debug builds, just like bug 1686743. I'm reasonably confident that they have the same root cause, so hopefully once we figure out what's happening in bug 1686743, we can get these patches landed.

(In reply to Mike Conley (:mconley) (:⚙️) (Catching up on needinfos) from comment #11)

From morgan in Matrix:

so it looks like one of the changes that pref causes is our dialog elements are now in internal frames in the a11y tree. I think those frames might be eating the events that we're waiting for in that test (we get a show for the frame, but not the dialog). not sure what needs to be changed there just yet, but sounds like we'll have to modify how we handle events for dialogs. I'll keep ya updated if I find a solution

We might want to file a follow-up bug for test_ui_modalprompt.html, unless fixing it as an accessibility blocker for MR1.

Asa, putting this on your radar in case this needs to be factored into MR1, accessibility-wise.

Hello! I've got a fix for this test -- should I attach a patch to your stack here? Or should I file something else as a dependent? :)

Flags: needinfo?(mconley)

(In reply to Morgan Reschenberg [:morgan] from comment #13)

Hello! I've got a fix for this test -- should I attach a patch to your stack here? Or should I file something else as a dependent? :)

Hi! Sorry for the late reply. Let's file a separate bug, if that's alright.

Flags: needinfo?(mconley)

I've got an additional patch which fixes some of the leaks. I have one last bc1 Fission-only leak left.

Depends on: 1704650
Attachment #9215285 - Attachment description: Bug 1686315 - Make sure SubDialog.abort calls SubDialog.close even if its contents haven't finished loading. r?pbz → Bug 1686315 - Fix up the last few tests to pass with content prompt subdialogs enabled or disabled. r?pbz
Blocks: 1702495
Pushed by mconley@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/bd716bdb723b
Fix up some tests to pass with content prompt subdialogs enabled or disabled. r=Gijs
https://hg.mozilla.org/integration/autoland/rev/2d10c21fd73f
Fix up more tests to pass with content prompt subdialogs enabled or disabled. r=Gijs
https://hg.mozilla.org/integration/autoland/rev/9da736ac2cee
Fix up the last few tests to pass with content prompt subdialogs enabled or disabled. r=Gijs
Flags: needinfo?(asa)
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: