Open Bug 1167937 Opened 9 years ago Updated 4 years ago

test_doc_busy.html attempts to install an empty XPI file, leaving behind a popup notification that interferes with other tests

Categories

(Core :: Disability Access APIs, defect, P3)

Unspecified
macOS
defect

Tracking

()

People

(Reporter: dao, Unassigned)

References

Details

(Whiteboard: [test disabled][mac2020_1])

Attachments

(1 file)

Attached image screenshot
See bug 1167716 comment 8.

It's unclear what kind of addon that is, maybe the "mochitests" origin displayed in the popup notification is an indication to someone.
Looks like this test attempts to install an empty XPI file: http://mxr.mozilla.org/mozilla-central/source/accessible/tests/mochitest/states/test_doc_busy.html?raw=1
Flags: needinfo?(surkov.alexander)
This test tests a11y behavior when the user requests to load a file. What are concerns?
Flags: needinfo?(surkov.alexander)
The doorhanger remains onscreen after the test which can affect later tests
Product: Testing → Core
Summary: Some add-on installation fails "because it appears to be corrupt", leaving behind a popup notification that interferes with tests → test_doc_busy.html attempts to install an empty XPI file, leaving behind a popup notification that interferes with other tests
Component: General → Disability Access APIs
(In reply to Dave Townsend [:mossop] from comment #3)
> The doorhanger remains onscreen after the test which can affect later tests

so if there's no other concerns then I assume generated escape key should do a trick?
You probably shouldn't use an XPI file in the first place if you just want to test the behavior of "downloading files".
(In reply to Dão Gottwald [:dao] from comment #5)
> You probably shouldn't use an XPI file in the first place if you just want
> to test the behavior of "downloading files".

This also should work. Iirc we test here the document's busy state, i.e. when the user clicks on a link, we listen for events that the document gets busy and then it gets not busy. So probably not every file type will do same job.
Blocks: 459563
I just hit this again with a completely different and innocent patch, so I'm gonna disable this test on 10.6 for the time being.
OS: Unspecified → Mac OS X
Whiteboard: [test disabled]
Keywords: leave-open
Keywords: leave-open
Dão, can this be closed?
Flags: needinfo?(dao+bmo)
This test is likely still broken.
Flags: needinfo?(dao+bmo)
Whiteboard: [test disabled] → [test disabled][mac2020_1]
Priority: -- → P3
Severity: major → S3

This test was changed in bug 1004061 to use a zip instead of an XPI. However, that still brought up the download dialog and didn't close it.

I rewrote this test in bug 1626851 so that it closes the download dialog after it finishes, which should deal with this problem. Unfortunately, now we're hitting an intermittent timeout, bug 1647666, which I'm still trying to resolve.

Depends on: 1004061, 1626851, 1647666
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: