Closed Bug 1555966 Opened 5 years ago Closed 5 years ago

Setting the src attribute on a cross-origin iframe in a fission window sometimes doesn't load the page

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Version:
Other Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla69
Project Flags:
Fission Milestone M4
Tracking Flags:
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:

  1. new set of patches on new m-c here
  2. old set of patches on old m-c here
  3. 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.

Flags: needinfo?(nika)

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.

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.

Flags: needinfo?(nika) → needinfo?(valentin.gosu)
Regressed by: 1551601

Can we use this bug to back it out? It also caused bug 1555034 so it's safe to say the fix is wrong.

Flags: needinfo?(valentin.gosu)

Yep, that's fine by me.

(Did you want me to do it, or will you?)

Since it's late Friday night for you I guess I'll just go ahead and do it.

Assignee: nobody → kats
Component: DOM: Content Processes → Networking
Pushed by kgupta@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/b23e6c13ffb9
Back out cset ecceef291b89 (bug 1551601) for regressions. rs=valentin

https://hg.mozilla.org/mozilla-central/rev/b23e6c13ffb9

Status: NEW → RESOLVED
Closed: 5 years ago
status-firefox69: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla69

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

Fission Milestone: --- → M4
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.