Setting the src attribute on a cross-origin iframe in a fission window sometimes doesn't load the page
Categories
(Core :: Networking, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox67 | --- | unaffected |
firefox68 | --- | disabled |
firefox69 | --- | fixed |
People
(Reporter: kats, Assigned: kats)
References
(Regression)
Details
(Keywords: regression)
I wrote a test for bug to exercise some APZ code with fission enabled, and while the test works on single runs, when run with --verify
it randomly fails both on try (all platforms) and locally (I ran on Linux debug). AFAICT what happens is that my test sets the src attribute on an iframe to a cross-origin URL. So this should load the iframe OOP (it's a fission window) but the iframe just doesn't load. I verified this visually (the contents of the iframe don't appear) and the onload event handler inside the iframe content also doesn't fire.
The previous iteration of patches for this test didn't have this problem. So I did three try pushes:
- new set of patches on new m-c here
- old set of patches on old m-c here
- old set of patches on new m-c here
The first and third fail, which indicates a regression in m-c somehere. I can bisect m-c to find out what caused it but it'll be a lot of try pushes so if you know what's going on already I can skip that step.
Assignee | ||
Comment 1•6 years ago
|
||
I just noticed that the try push from (3) above has a crash in the opt run (the debug run is showing the failure I was talking about). That might be a separate bug, since DOM code shouldn't crash no matter what the test is doing.
Assignee | ||
Comment 2•6 years ago
|
||
The regression range in m-c (based on try pushes #2 and #3 from comment 0) is https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5cc220ddf028de011a922042ee9ba691b94d055d&tochange=909f78f4ebaed6cfd473735f6140a88ee7de3c0c
Bisection try push #1 at m-c 2bb77ed1fcc5ad06f91612d419160f54c09369db: bad
Bisection try push #2 at m-c 3a79d3be67486be1d30bda47988cf8c76ee3a3ee bad
Bisection try push #3 at m-c c3f75e0814271535427e68195ccdabe61d3c95dc bad
Bisection try push #4 at m-c 267d1abce0581f08bdefc977f24e421c161e603f good
Bisection try push #5 at m-c fa7dcd1f369cf19b7af37d9cfc953fe1d131e1c4 bad
nika suggested I back out bug 1551601 so I did that locally and the problem went away. (Her suggestion is also why I chose those two revisions for bisection pushes #s 4 and 5). Once that last try push is done it should confirm this, but so far it seems like bug 1551601 is to blame.
Comment 3•6 years ago
|
||
Can we use this bug to back it out? It also caused bug 1555034 so it's safe to say the fix is wrong.
Assignee | ||
Comment 4•6 years ago
|
||
Yep, that's fine by me.
Assignee | ||
Comment 5•6 years ago
|
||
(Did you want me to do it, or will you?)
Assignee | ||
Comment 6•6 years ago
|
||
Since it's late Friday night for you I guess I'll just go ahead and do it.
Comment 8•6 years ago
|
||
bugherder |
Updated•5 years ago
|
Comment 9•5 years ago
|
||
Retroactively moving fixed bugs whose summaries mention "Fission" (or other Fission-related keywords) but are not assigned to a Fission Milestone to an appropriate Fission Milestone.
This will generate a lot of bugmail, so you can filter your bugmail for the following UUID and delete them en masse:
0ee3c76a-bc79-4eb2-8d12-05dc0b68e732
Updated•3 years ago
|
Description
•