Open
Bug 1295245
Opened 8 years ago
Updated 2 months ago
Resize events on iframes don't fire if iframe is hidden
Categories
(Core :: Web Painting, defect)
Tracking
()
NEW
People
(Reporter: rassinator, Unassigned)
References
()
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
Steps to reproduce:
https://gist.github.com/Rhathe/9e04aab4d3e55346ab8b6c8b55d71007
Host all the files locally, go to iframe-holder.html. Manually change window size.
Actual results:
Console logs only 'second-iframe resize' and 'third-iframe resize' when resizing window.
Expected results:
Console should log 'second-iframe resize', 'third-iframe resize', 'fourth-iframe resize', and 'fifth-iframe resize' when resizing window.
Comment 1•8 years ago
|
||
I copied the test case to my people account so it's easier to access. Firefox's behaviour is different from Chrome, which does log the "expected results". I'm not sure which spec covers this behaviour (if any).
Status: UNCONFIRMED → NEW
Component: Untriaged → DOM: Events
Ever confirmed: true
Product: Firefox → Core
This is more like a layout issue, given that PresShell fires resize event.
Component: DOM: Events → Layout
Comment 3•8 years ago
|
||
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #1)
> I copied the test case to my people account so it's easier to access.
> Firefox's behaviour is different from Chrome, which does log the "expected
> results". I'm not sure which spec covers this behaviour (if any).
The spec says:
> For each fully active Document in docs, run the resize steps for that Document, passing in now as the timestamp.
and the resize steps would fire the event. However, before that, the spec also says:
> If there are a nested browsing contexts B that the user agent believes would not benefit from having their rendering updated at this time, then remove from docs all Document objects whose browsing context is in B.
An <iframe> with "display: none" would fall into the class that nested browsing context would not benefit from having their rendering updated. We may decide to put "visibility: hidden" into the same class as well.
However, "visibility: hidden" is clearly not in that class for now, because we still run animation frame callback for those nested documents (but not for those with "display: none"), so we are inconsistent here.
Given other browsers all fire resize event for nested document with "visibility: hidden", we probably want to follow them.
Comment 4•8 years ago
|
||
I guess this is an issue for the view system.
Component: Layout → Layout: View Rendering
Assignee | ||
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•