1659963 - Enable test_bug927196.html on Fission

Status: RESOLVED DUPLICATE of bug 1658791

(Core :: DOM: Networking, defect, P3)

Description

[Olli Pettay [:smaug][[e-mail]]]

At least locally the test passes with Fission

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Er, I didn't test xorigin .

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

...but still passes with --enable-xorigin-tests

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=4e078e42207b1a0d62e61801b980dc1f18e96aed

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Attachment: Bug 1659963 - Enable test_bug927196.html on Fission, r=edgar

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Lovely, this fails on try, but not locally.

Comment 6

[Mirko Brodesser (:mbrodesser-Igalia), offline until April 25h]

Also couldn't reproduce this locally, but it still fails on try.

Comment 7

[Mirko Brodesser (:mbrodesser-Igalia), offline until April 25h]

The failure is reproducible locally when executing the test two times in a row (e.g., with running ./mach mochitest --enable-xorigin-tests --enable-fission --run-until-failure --keep-open=false ./dom/base/test/test_bug927196.html). Not reproducible if run without xorigin iframes and Fission, hence presumably not a test-code issue.

Comment 8

[Neha Kochar [:neha]]

It fails with XMLHttpRequest should not be mozSystem (2) - got true, expected false(In reply to Mirko Brodesser (:mbrodesser) from comment #7)

The failure is reproducible locally when executing the test two times in a row (e.g., with running ./mach mochitest --enable-xorigin-tests --enable-fission --run-until-failure --keep-open=false ./dom/base/test/test_bug927196.html). Not reproducible if run without xorigin iframes and Fission, hence presumably not a test-code issue.

Thanks, Mirko for the repro. It could still be a test issue, if it is because of test making incorrect assumptions or not waiting enough, etc.
It fails with <XMLHttpRequest should not be mozSystem (2) - got true, expected false>. What could be the cause of this?

Comment 9

[Mirko Brodesser (:mbrodesser-Igalia), offline until April 25h]

:neha: I'm looking into it.

Comment 10

[Mirko Brodesser (:mbrodesser-Igalia), offline until April 25h]

Pernosco run.

Comment 11

[Mirko Brodesser (:mbrodesser-Igalia), offline until April 25h]

The problem seems to be in XMLHttpRequestMainThread::InitParameters:

permission != nsIPermissionManager::ALLOW_ACTION is true when the test doesn't fail, and false when it fails.

Comment 12

[Mirko Brodesser (:mbrodesser-Igalia), offline until April 25h]

SpecialPowers.pushPermissions seems to be buggy, it doesn't always remove the pushed permissions (manually removing them using SpecialPowers.removePermission leads to passing runs of the STR described in c7).

Not necessarily part of this bug, but _delayCallbackTwice looks suspicious.

Presumably, the bug is that _applyPermissions sends and async message instead of waiting for a promise.

SimpleTest.finish() seems to call the wrong instance of SpecialPowers. At least _permissionUndoStack is empty when flushing, but it's filled in pushPermissions.

Comment 13

[Mirko Brodesser (:mbrodesser-Igalia), offline until April 25h]

Attachment: Bug 1659963: document `SpecialPowers.removePermission`. r=kmag

Helps understanding it.

Comment 14

[Kris Maglione [:kmag]]

The pushPermissions/flushPermissions issue will be fixed by bug 1658791.

Comment 15

[Neha Kochar [:neha]]

Based on the analysis in comment 12, it's a SpecialPowers issue and therefore, should be M6c.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/14b95c9e82c4
document `SpecialPowers.removePermission`. r=kmag

Comment 17

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/14b95c9e82c4