Open Bug 1229707 Opened 9 years ago Updated 5 months ago

load event not raise for nested iframes without src

Categories

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

Product:
Core
Component:
DOM: Navigation
Version:
42 Branch
Type:
defect

Tracking

()

People

(Reporter: miherlosev, Unassigned)

References

(Depends on 1 open bug)

Details

Attachments

(1 file)

Bug1229707-Test.html
570 bytes, text/html
Details 
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0
Build ID: 20151029151421

Steps to reproduce:

1)Create a page with the following markup:
<html>
	<body>
		<h1>Top level document</h1>
		<script>
			var iframe = document.createElement('iframe');
			iframe.id = 'iframe1';
			iframe.addEventListener('load', function () {
				var iframeDocument = this.contentDocument;
				var nestedIframe = iframeDocument.createElement('iframe');
				nestedIframe.id = 'iframe2';
				nestedIframe.addEventListener('load', function () {
					alert('nested iframe load event');
				});
				iframeDocument.body.appendChild(nestedIframe);
			});
			document.body.appendChild(iframe);
		</script>
	</body>
</html>
2)Open it in browser


Actual results:

Alert with text 'nested iframe load event' didn't show


Expected results:

I expect the alert with text 'nested iframe load event'
Confirmation: I also fail to see an alert display. Is this desired behavior or should an alert display?
 20151029151421
Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:42.0) Gecko/20100101 Firefox/42.0
Status: UNCONFIRMED → NEW
Ever confirmed: true
Component: Untriaged → Layout: HTML Frames
Product: Firefox → Core
The relevant spec bit starts at https://html.spec.whatwg.org/#the-iframe-element:process-the-iframe-attributes I believe.

What that will do is jump to https://html.spec.whatwg.org/#process-the-iframe-attributes and land in the

  Otherwise, if the element has no src attribute specified, and the user agent is
  processing the iframe's attributes for the "first time"

case, which is in fact supposed to queue up a load event.

In our case the problem is that we do the frame recursion check before we create the child browsing context, iirc, so we never perform the about:blank load in this case (because the parent document has the same URI) and we don't have a special-case for firing onload manually in the no-src case, because we depend on the about:blank load to do that.

Fixing this probably requires sorting out 543435 and company and in general aligning closer with the spec in terms of about:blank handling for iframes...

Michelle, note that this is not a layout issue; load events are not dependent on layout.  One way to tell in general whether something is a layout issue or not, by the way, is whether doing all the same things in a display:none subtree shows the same problem.
Component: Layout: HTML Frames → Document Navigation
Depends on: sync-about-blank
Note that this is conceptually similar to bug 473396 and that when I tried to just skip the recursion check for about:blank in that bug things _still_ did not work, precisely because of the non-sync about:blank issues.
Attached file Bug1229707-Test.html —

Attaching testcase from comment 0 to make it easier to run.

This looks like it works as expected now. Since this not my wheelhouse, :neha, would you know who would be suitable to confirm this is fixed (and add a automated test if needed)?

Flags: needinfo?(nkochar)

Kris, can you confirm this and add a test, if we don't already have one?

Flags: needinfo?(nkochar) → needinfo?(kmaglione+bmo)

The attached test case shows that this is now working but we should find out why this is now working. Did we accidentally break something else?

This isn't fixed, strictly speaking. It just works when there's one level of nesting now. If someone tries to create two levels of nested about:blank iframes, it will still fail.

I think we probably need to update the recursion check to ignore either about:blank or an empty src attribute, since those will always start out empty, and can't lead to static infinite recursion.

Flags: needinfo?(kmaglione+bmo)

Assigning to kmag to get back to, after the current Fission work is done.

Assignee: nobody → kmaglione+bmo
Priority: -- → P3

AFAICT, this already works without fixing bug 543435. Am I missing something?

Severity: normal → S3

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Assignee: kmaglione+bmo → nobody
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: