1878166 - For lazy loaded frames the "browsingContext.#onContextAttached" handler is not invoked

Status: RESOLVED FIXED

(Remote Protocol :: WebDriver BiDi, defect, P2)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Attachment: lazy-frame.html

When employing lazily loaded iframes in an HTML document, they are not added to the DOM unless the user scrolls to make them visible. Please check the attached test case.

According to the specification, the iframe should be promptly added to the DOM, with the load delayed:
https://html.spec.whatwg.org/multipage/iframe-embed-object.html#the-iframe-element:html-element-insertion-steps

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I've checked this again this morning with the DOM inspector and I actually can see the iframe attached. I think that yesterday night I was trying it with the Browser Toolbox from the parent process. I would have to check this again.

Neverthless the problem can be seen when running the following Puppeteer test:
https://github.com/puppeteer/puppeteer/blob/0a9f6d670a86c6d1399501b2780fbb46cbe97b2c/test/src/frame.spec.ts#L277-L288

Just replace it with it.only and run the following command (if you run multiple times you can also use --no-install to skip the Puppeteer install step):

mach puppeteer-test --setpref="remote.log.level=Trace" --setpref="remote.log.truncate=false"

Note that Puppeteer only lists two browsing contexts (top frame and first frame) because our WebDriver BiDi implementation sends out a browsingContext.contextCreated event only for that first frame but not the second one. This means that internally we do not get a browsing-context-attached observer notification for the 2nd frame, which is lazy loaded.

So maybe this issue is IPC related?

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2]]

With the details as given on bug 1878229 for the inspector I checked with the Browser Toolbox and it works fine as well. That means the issue here is definetely not a delayed insertion into the DOM.

Further I added log entries for browsing-context-attached now in our Webdriver BiDi code and I can see that we actually get notifications for both frames including the lazily loaded one, and also emit the attached event via the EventEmitter. While for the first frame our BrowsingContext.#onContextAttached handler is called, it does not happen for the lazy loaded iframe.

So this is a bug in our WebDriver BiDi implementation. Sorry for the noise.

Comment 3

[Julian Descottes [:jdescottes]]

The test page attached here has an iframe which fails to load (goes directly to an error page). I modified the test case to have a valid iframe src at https://bug1878166-testcase.glitch.me/, and with this I get the expected number of contextCreated events. The second browsingContext.contextCreated event is emitted when the lazy loaded frame becomes visible.

I imagine we should check what happens for iframes loading an error URL, but I don't think that's relevant for that puppeteer test?

The trigger for contextCreated is supposed to be:

When the create a new browsing context algorithm is invoked, after the active document of the browsing context is set ...

I think the active document is only set when we start loading the iframe?

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Thank you for the updated test Julian. I didn't notice that when uploading the test case.

I've re-checked myself the flow of events in our BiDi code and I can second that we do not see a browsing-context-attached notification until the lazy loading iframe has scrolled into view. Enabling the BrowsingContext:5 logs also verified that because D/BrowsingContext Creating 0x200000002 in Child was fired when the iframe gets visible.

I'm not sure why we aren't emitting the notification immediately given that the lazy iframe gets added right away to the DOM with about:blank being loaded.

Olli, do you know why we are doing that? Could we change that behavior or are we forced to do it that way? Thanks!

Comment 5

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

I think canadahonk is looking into about:blank handling in iframes.

I would expect there to be about:blank in iframes and if so, there should be also notification about the relevant browsing context.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #5)

I would expect there to be about:blank in iframes and if so, there should be also notification about the relevant browsing context.

Yes, that is what I see but there is no browsing-context-attached notification for this lazy loaded iframe. Removing lazy it works as expected.

Comment 7

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

Well, there isn't a new browsing context when the iframe loads. It is the same browsing context as what about:blank has.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Right, but exactly that one for about:blank isn't getting send. I only get the notification when I manually scroll down the page until the iframe becomes actually visible in the viewport.

Comment 9

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

Oh, I misunderstood the comment https://bugzilla.mozilla.org/show_bug.cgi?id=1878166#c6 then.
Is it possible that we don't create the about:blank early enough? There is a profiler marker for the initial about:blank

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+2]]

To make it easier for investigation I just created a profile for this specific scenario: https://share.firefox.dev/3QYwR8R

Please take the following into account:

• I've updated the starting point to when we triggered the navigation to the page that contains a normal and a lazy frame
• You can see that a browsingContext.contextCreated event is sent pretty quickly for the normal frame but that's all
• Around 28s into the profile I started to scroll down the page to reach the lazy frame
• At the 31.5s timestamp I reached the lower end of the page and the browsing context gets created and a browsingContext.contextCreated event is emitted as well

I hope that helps. If something is still missing please let me know. Thanks!

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Oliver, gently ping. Could you please take a look? Thanks.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Olli, could you maybe have a quick look at the profile, which I've created and referenced in my comment 10? Maybe you can see something which could be the reason that no browsing-context-attached notification is sent for the lazy iframe?

Comment 13

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

We seem to create the about:blank when the iframe is first time accessed. And that is when you get browsing-context-attached, as expected, given the current implementation.

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #13)

We seem to create the about:blank when the iframe is first time accessed. And that is when you get browsing-context-attached, as expected, given the current implementation.

When checking the profile as given above and filtering for the browsing-context-attached marker, I do see two notifications but those should be for the top-level browsing context and the first non-lazy frame on the page. The notification for the lazy frame is send out around 32s when it became visible by scrolling.

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Just chatted with Olli and he confirmed that this is a bug in Gecko that we have to fix. As such let me file a platform bug as dependency so that it is correctly tracked by the team, and we may also have to make small adjustments on our side or adding a specific test - so keeping this bug for BiDi would make sense.

Comment 16

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This failure is not a P2 one anymore.

Comment 17

[Henrik Skupin [:whimboo][⌚️UTC+2]]

The DOM changes that landed recently via bug 1905418 fixes this bug. There is no additional work needed. The related Puppeteer tests are passing as well for WebDriver BiDi.