1622312 - Crash in BrowsingContext::CanAccess with a click on a cross-origin iframe (Fission disabled)

Status: RESOLVED WONTFIX

(Core :: DOM: Navigation, defect, P1)

Description

[Didier]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:74.0) Gecko/20100101 Firefox/74.0

Steps to reproduce:

Navigate to :
http://www.geneagier.com/photos_civils.php
choose "Commune" in "Departement" then choose a "Registe" and click

Actual results:

Tab crashes each times
Before Version 74, no issue with this.
Crash report is : bp-915abe37-ed73-414c-a7da-b9ad40200313

Expected results:

A picture displayed in the "iframe".

Comment 1

[Didier]

The same issue exists with Windows10 and Firefox74

Comment 2

[Claas Augner [:claas]]

See also my comments in bug 1576262 for new tab crashes in FF 74 on Windows 10 when uploading files:
https://bugzilla.mozilla.org/show_bug.cgi?id=1576262#c6
https://bugzilla.mozilla.org/show_bug.cgi?id=1576262#c7

Comment 3

[Claas Augner [:claas]]

After taking a closer look at file upload form in question (legacy code) which also uses an iframe, I was able to trim down the code as follows:

<form method="POST" enctype="multipart/form-data" target="iframe_name">
  <input type="file" name="file" />
  <input type="submit" value="Upload"  />
  <iframe name="iframe_name" src="#" style="display:none"></iframe>
</form>

Although this snippet does not seem to produce a crash on its own (i.e. in an otherwise blank HTML page), it always crashes in the context of our web application.

Update: Here's my corresponding crash report from a fresh Firefox Portable 74.0 Portable (64-Bit) installation:
https://crash-stats.mozilla.org/report/index/3236f786-2ead-403a-8857-d57140200316

Comment 4

[Claas Augner [:claas]]

Just figured that removing the src avoids the crash, i.e. the tab only crashes if the targeted <iframe> is not empty.:

- <iframe name="iframe_name" src="#" style="display:none"></iframe>
+ <iframe name="iframe_name" style="display:none"></iframe>

The website mentioned by Didier above opens a link in a non-empty iframe, so this seems to be the common denominator:

<!-- Source: http://www.geneagier.com/photos_civils.php?page=loire&type=pho&insee=42053&commune=chateauneuf -->

<a href="prec_suiv_phet.php?typeph=pho&amp;insee=42053&amp;photo_reg=chateauneuf&amp;reg=1850_1869 D&amp;com_typo=Châteauneuf&amp;nbphot=147" target="I1">1850_1869 D</a>

<!-- ... -->

<iframe name="I1" src="pages_ph_et.htm" marginwidth="1" marginheight="0" width="1179" height="708" align="right">
      Votre navigateur ne prend pas en charge les cadres inseres ou est actuellement configure pour ne pas les afficher.</iframe>

Comment 5

[Ethan Tseng [:ethan]]

This bug is related to bug 1576262 and seems to be critical.

Comment 6

[Didier]

I found a solution to solve the crash :
Code before
<tr> <td colspan="4" width="1208" height="720"><!--mstheme--><font face="Comic Sans MS"> <p align="center"> <iframe name="I1" src="pages_releves_livre_or.htm" width="1179" height="708" align="right" marginwidth="1" marginheight="0"> Votre navigateur ne prend pas en charge les cadres insérés ou est actuellement configuré pour ne pas les afficher.</iframe> </font></td> </tr>
Code After :
<tr> <td colspan="4" width="1208" height="720"><!--mstheme--><font face="Comic Sans MS"> <p align="center"> <iframe name="I1" src="pages_releves_livre_or.htm" width="1179" height="708" align="right" marginwidth="1" marginheight="0"> Votre navigateur ne prend pas en charge les cadres insérés ou est actuellement configuré pour ne pas les afficher.</iframe> </td> </tr>

I just suppressed the tag "</font>" just after "</iframe>" and now the site http://geneagier.com works very well.
Strange behavior and I don't understand why this tag was a problem...
Thanks Claas Augner, it's you to help me with your comment 4.

Comment 7

[Daniel Bodea [:danibodea]]

The crash log signature from the description is the same as the one in bug 1576262 so I would normally dupe this but on the other.
I would have attempted to find this bug's regressor, but I cannot reproduce it, and also, bug 1576262 has e possible regression range.

If I were to overlook comment 6 that states to have found a fix for the bug, I would like to ask for detailed explanations on the steps to reproduce written in comment 0 so I could try and find it's regressor myself.
Didier, Can you explain what exactly I need to do on the "http://www.geneagier.com/photos_civils.php" website to get a crash?

Thank you for your contribution!

Comment 8

[Claas Augner [:claas]]

Attachment: bug-1622312.html

Comment 9

[Claas Augner [:claas]]

(In reply to Bodea Daniel [:danibodea] from comment #7)

The crash log signature from the description is the same as the one in bug 1576262 so I would normally dupe this but on the other.

I had briefly outlined in that bug that these bugs possibly aren't duplicates, because this one only appeared in Firefox 74 (i.e. the causing code worked in Firefox 73), whereas the crash log signature was first seen in Firefox 70.

Didier, Can you explain what exactly I need to do on the "http://www.geneagier.com/photos_civils.php" website to get a crash?

Based on Didier's comment (merci !), I was able to compile the attached minimal example to make Firefox crash:
https://crash-stats.mozilla.org/report/index/116e09ee-71dd-41f2-bfc9-b8b690200318

Comment 10

[Andrew McCreight (out of office until 8/21) [:mccr8]]

I wasn't able to reproduce a crash on OSX by clicking on the attached test case and clicking on the button, nor by downloading the test case and doing the same, either in my regular profile or in a clean profile. Is there something else I need to do?

Comment 11

[Claas Augner [:claas]]

Attachment: bug-1622312-capture.gif

Comment 12

[Claas Augner [:claas]]

(In reply to Andrew McCreight [:mccr8] from comment #10)

Is there something else I need to do?

No, that's all you need to do, I have added a screen capture.

I have only heard from Windows 10 users and reproduced it myself with the Mozilla Firefox, Portable Edition, but not all Windows installations are affected either.

Comment 13

[Andrew McCreight (out of office until 8/21) [:mccr8]]

I wasn't able to reproduce on Windows, either. Can you reproduce in safe mode? Maybe there's some addon that is causing the issue? the test case looks so simple it is hard to understand why we're not seeing more problems.

Comment 14

[Claas Augner [:claas]]

The instance I reproduced the bug with had a fresh profile with zero extensions.

Just verified again with a separate fresh instance of FirefoxPortable_74.0_English.paf.exe (md5: fb239393cf0c26c3afd98b465fb05436) and got exactly the same result: bp-8312e151-b617-45bc-bdf9-581500200318

If you cannot reproduce the issue with the exact same instance, it must be hardware-specific or related to OS settings. On the other hand, Didier apparently experienced the issue on Ubuntu.

If you like, I can send you a ZIP of the fresh portable instance via email, if that helps.

PS: Same behaviour in safe mode: bp-3a8e0121-82d4-41fd-bde3-852680200318

Comment 15

[Pascal Chevrel:pascalc (PTO until Sept 2)]

I can also reproduce the crash with a fresh profile on 74:
https://crash-stats.mozilla.org/report/index/f0e456a3-de9a-451e-82ac-da9650200318

Comment 16

[Andrew McCreight (out of office until 8/21) [:mccr8]]

If somebody who can reproduce it could use mozregression to narrow down what might have caused the issue, that would be useful.

Comment 17

[Pascal Chevrel:pascalc (PTO until Sept 2)]

I cannot reproduce the crash with mozregression (I used mozregression --find-fix --bad 74 -a https://bugzilla.mozilla.org/attachment.cgi?id=9134162)

Comment 18

[Didier]

(In reply to Bodea Daniel [:danibodea] and Claas Augner [:claas] from comment #7 and #8)

With the little html file example from Class (Comment #8), I reproduce the crash.
In the example file if I removed the </font> line 8 , the crash don't happen.
It is the same update that I done in "http://www.geneagier.com/photos_civils.php" page and 5 others pages calling the same function.

Comment 19

[Claas Augner [:claas]]

I just tried and couldn't reproduce on:

• 73.0.1 (FirefoxPortable_73.0.1_English.paf.exe)
• 75.0b2 (FirefoxPortableDeveloper_75.0_Beta_2_English.paf.exe).

Comment 20

[Claas Augner [:claas]]

When running with FirefoxPortable.exe -console, the crash causes the following message in the console window:

[Parent 328, Gecko_IOThread] WARNING: file z:/task_1583751780/build/src/ipc/chromium/src/base/process_util_win.cc, line 160

Which seems to refer to the following line:
https://dxr.mozilla.org/mozilla-central/rev/a5333943843b535005841def964f9d3588f15780/ipc/chromium/src/base/process_util_win.cc#160

Comment 21

[Claas Augner [:claas]]

And here's a full Firefox Profiler capture (crash at ~1.62s): https://perfht.ml/2IXW2or

(Captured via Remote Debugging from Firefox Nightly 76.0a1.)

Comment 22

[Claas Augner [:claas]]

Attachment: bug-1622312-profiler-capture.png

The Profiler capture suggests to me that there was a problem allocating virtual memory.

Comment 23

[Tim Spurway [:tspurway]]

Hi Andrew, do you know who could own this bug?

Comment 24

[Andrew Overholt [:overholt]]

mccr8's been investigating so let's assign it to him until we fine a better owner.

There are a bunch of mentions of Firefox Portable here. Could it be something with that, Claas?

Comment 25

[Claas Augner [:claas]]

Not specific to Firefox Portable, our users who experienced this issue have been using Firefox Desktop.

Comment 26

[Andrew McCreight (out of office until 8/21) [:mccr8]]

I was able to reproduce the crash using the test case on the version of Firefox release from Mozilla's website.

I then was able to use mozregression on release, and I could reproduce it there: mach mozregression --bad 74 --good 73 --repo mozilla-release

I think the resulting regression range is just the merge from beta to release: https://hg.mozilla.org/releases/mozilla-release/pushloghtml?fromchange=01bf137f4353fcb5dd9580922318c00ef55984b4&tochange=e98fd13a1a1acf6f7df56c1917a1e392c624f5c7

So, there must be some difference between Firefox 74 built as Nightly and Firefox 74 built as Release that is causing the crash.

One guess I had was that it might be related to enabling document channel, but it looks like that is enabled in release. I also tried setting browser.tabs.documentchannel and dom.serviceWorkers.parent_intercept to false, but that did not fix the crash.

Comment 27

[Andrew McCreight (out of office until 8/21) [:mccr8]]

Next, I used mozregression on beta, again assuming that 74 was not working: ./mach mozregression --bad 74 --good 73 --repo mozilla-beta.

This gave me a more interesting regression
https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=607417212e2592dc01b2dd55b6a88c9c15509450&tochange=efcde5f316e0dffca74535da62562e88976a88bf

This includes "Arthur Iakab — Backed out 4 changesets (bug 1582832) for causing Bug 1614259 and Bug 1615508 a=backout"

I guess that means bug 1582832 fixed this. I'm not sure why this doesn't reproduce on 74 Nightly.

Comment 28

[Andrew McCreight (out of office until 8/21) [:mccr8]]

Trying to find when this was fixed on beta via mach mozregression --bad 74 --find-fix --repo mozilla-beta turned up another large merge... the merge to 75 maybe? https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=2e6e177dbbff7020af4ba28f128f01f68aaada25&tochange=3bd67f111cdf69baa5710c10b6b0a87146d11e2f

Comment 29

[Andrew McCreight (out of office until 8/21) [:mccr8]]

It seems unlikely that we'd put out a dot release that would reland bug 1582832, given the problems that caused it to be backed out in the first place, so I'm not sure how much there is to do here, besides landing a test.

Kris, in bug 1582832 comment 28, you said "This should only really matter when Fission is enabled, and it can't be enabled on beta.", but the test case here doesn't involve Fission and looks pretty straightforward. Is there anything to learned from it?

Comment 30

[Andrew McCreight (out of office until 8/21) [:mccr8]]

(In reply to Andrew McCreight [:mccr8] from comment #27)

I guess that means bug 1582832 fixed this. I'm not sure why this doesn't reproduce on 74 Nightly.

To answer my own question, this doesn't reproduce on 74 Nightly because the fix was still on Nightly. It didn't get backed out until 74 merged to beta.

Comment 31

[Andrew McCreight (out of office until 8/21) [:mccr8]]

Ryan, given that the volume seems pretty low and a backport would be risky, should we wontfix this (it only affects 74).

Comment 32

[Pascal Chevrel:pascalc (PTO until Sept 2)]

I wouldn't want to backport a risky change in a potential dot release while we are 2 weeks away from 75 which is not affected, marking as wontfix for 74.

Comment 33

[BugBot [:suhaib / :marco/ :calixte]]

:mccr8, since this bug is a regression, could you fill (if possible) the regressed_by field?
For more information, please visit auto_nag documentation.

Comment 34

[Andrew McCreight (out of office until 8/21) [:mccr8]]

I don't know. Some Fission refactoring work.

Comment 35

[Chris Peterson [:cpeterson]]

This crash is related to or a dupe of CanAccess crash bug 1576262.

Closing this bug as WONTFIX because this crash only affects 74 Release and has been fixed in 75.