Jquery animations take 0 time when <iframe name="hidden"> is included in the source
Reported by
drewcif...@gmail.com,
Nov 15 2016
|
|||||||||||||
Issue descriptionChrome Version : 54.0.2840.71 m (64-bit) URLs (if applicable) : https://beta-test.veracast.com/test_hidden1_iframe.html (works), https://beta-test.veracast.com/test_hidden_iframe.html (doesn't work) Other browsers tested: Add OK or FAIL, along with the version, after other browsers where you have tested this issue: Safari: ? Firefox: OK IE: OK What steps will reproduce the problem? (1) inlcude jquery (2) add an animation in window.on("load") //(works so far) (3) add <iframe name="hidden"></iframe> //(now animations take 0 time) What is the expected result? What happens instead? Please provide any additional information below. Attach a screenshot if possible.
,
Nov 15 2016
Could you please provide us the sample html file or sample test case to reproduce the issue , that can help us to triage the issue better. Also provide us the expected and actual result screenshot. Thanks !
,
Nov 15 2016
<!DOCTYPE html>
<html>
<head>
<script src="/assets/jquery.min.js"></script>
<script>
$(window).on("load",function(){
$("#cover").fadeOut(3000);
});
</script>
</head>
<body>
<div id="cover" style="background:#000;color:#fff;font-size:32px;padding:200px;position:absolute;top:0px;bottom:0px;right:0px;left:0px;">
fade fade fade
</div>
<iframe name="hidden" id="hidden">
</body>
</html>
The attached file shows what it should show on load. A black box covering the whole page that fades out in 3 seconds. What happens is the fade out animation takes 0 seconds so you never see the black box at all. Any other animations added to the page will also take 0 time. so if i animated the width of the iframe for example it would take 0 time no matter what I set the duration to.
,
Nov 15 2016
If you just change the name of the iframe from hidden to hidden1 the animations then work. This problem only exists in chrome.
,
Nov 17 2016
Any word on this? I need my iframe to have the name="hidden" attribute and my site doesn't not work properly because of this bug. Animations work fine in older versions of jquery, but not in the most recent version. I'd say it was a jquery bug, but it works in every other browser...so it's got to be something with chrome itself.
,
Nov 17 2016
Just click the links in my first post to see...it's pretty clear.
,
Nov 22 2016
,
Nov 29 2016
Thank you for providing more feedback. Adding requester "hdodda@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 9 2016
,
Dec 12 2016
Routing to Animation team. This is quite reproducible for me, and I'm wondering why the name attribute affects how animations work.
,
Dec 12 2016
jQuery is probably doing magical things to elements with a name attribute.
,
Dec 12 2016
Chrome must also be doing a little magic of it's own since other browsers are not affected.
,
Dec 13 2016
Looks like document.hidden is being set to a Window object for some reason causing
// Go to the end state if fx are off or if document is hidden
if ( jQuery.fx.off || document.hidden ) {
opt.duration = 0;
to set the animation duration to 0.
,
Dec 13 2016
,
Dec 13 2016
Looks like we're following the spec here. If you have an iframe with a name attribute set it will be accessible via document[name]. Example: http://jsbin.com/qamimafajo/edit?html,js,console Spec: https://html.spec.whatwg.org/multipage/dom.html#dom-tree-accessors:document-15 It's concerning that this is not interoperable behaviour with other browsers. Passing over to HTML team to decide what to do here.
,
Dec 13 2016
Here's a tiny fiddle which demonstrates the difference; FF 50.0.2 alerts false; Chrome alerts [object Window]. https://jsfiddle.net/0141z8ty/ It appears Firefox doesn't implement the named items collection for iframes at all. Would be interested to know what Edge and Safari do with this. document.hidden comes from this spec: https://www.w3.org/TR/page-visibility/#sec-document-interface
,
Dec 13 2016
alancutter@ thanks for your analysis! Adding bindings team as bindings are responsible for how named property is reflected. As it seems we are following the spec, probably other browsers also have to follow the spec. The jQuery code snippet seems no guilty for using |document.hidden| there. drewcifer0@, probably "hidden" is not a good name to use for iframe, as it collides with a name already used for Document's property.
,
Dec 13 2016
Did a quick check on Safari and Edge. Safari alerted "[object Window]" as Chrome. Edge13/IE12 alerted "false" as FF50 did.
,
Dec 13 2016
To follow all specs, in general, we also need to take [OverrideBuiltins] extended attribute into consideration. But in this case, we don't have it on Document interface, so document.hidden does not override built-in attribute and must return the visibility. In bindings layer, we use a hacky trick to handle these "named items" of document because of performance concern. It is the cause of this issue.
,
Dec 14 2016
+domenic@ as an expert of spec things [Context of the issue] Suppose that we have a) document.hidden DOM attribute, and b) <iframe name="hidden"> then, which document.hidden should point to? [Current behavior] Safari, Chrome: the iframe's contentWindow FF, Edge: the built-in attribute https://html.spec.whatwg.org/multipage/dom.html#the-document-object 3.1.1 The Document object says that the Document interface supports named properties with [OverrideBuiltins], so the <iframe name="hidden"> should have priority over the built-in attribute named "hidden", and then, document.hidden should point to the iframe's contentWindow, I think. domenic@, what do you think? Do you know why FF returns the built-in attribute? Any special reasons?
,
Dec 14 2016
Yes, your analysis seems correct. Chrome is correct and as far as I can tell Firefox is not. Let's see if Boris can see anything we missed. Otherwise we should open Firefox/Edge issues and write web platform tests.
,
Dec 14 2016
Document is [OverrideBuiltins], and Firefox correctly implements that. The disagreement here is in terms of what causes names to be exposed on the document at all. Here Firefox is somewhat more restrictive than the current spec in terms of what it exposes. Specifically, we expose only the following: 1. img, form, applet, embed, object elements with the given name. Note that iframe is not in that list. 2. applet, embed, object with the given id. 3. img with the given id that also has a name. That corresponds to https://html.spec.whatwg.org/multipage/dom.html#dom-document-nameditem-filter with "applet" and "iframe" dropped from the first bullet, "embed" added to the second bullet, and all <object> and <embed> being considered exposed. I don't believe we've ever exposed <iframe> elements here in Gecko. I just checked the blame on our tag whitelist (img, form, applet, embed, object) there and it dates back to sometime in 1998, before we actually had niceties like issues associated to all checkins. Edge does expose named iframes, with semantics like Blink/WebKit/spec but doesn't do the [OverrideBuiltins] behavior, as far as I know. I'm guessing when the spec was written is took the majority behavior for iframes and specified it, but I'm not sure it really carefully considered the breakage implications of exposing named things on document. If it were possible for everyone to stop exposing <iframe> here, it would be a much better solution in terms of not creating web developer gotchas than adding iframes to the exposure list in Gecko. Or if it were possible for everyone to match edge in not making documents [OverrideBuiltins]. Or both...
,
Dec 15 2016
Thanks for the input. Got better understanding. IMHO, if we think that shadowing the built-in attributes is problematic (like this issue), then dropping "iframe" is not sufficient. Other DOM objects can still override the built-in attributes. Dropping [OverrideBuiltins] makes sense to me for that purpose. Anyway, I close this issue for this specific case for this moment. I agree that there is room for discussion to update the spec, but until we reach to a new consensus, Blink is currently working as intended following the current spec.
,
Dec 15 2016
#23 - it might makes sense, but it is probably not web-compatible. Unfortunately, a lot of pages used to refer to elements using document.foo before foos were introduced into standards. I hate this. :(
,
Dec 15 2016
Uh? what about the problem? I mean...our website works in all major browsers except chrome. Does the jquery team need to fix something? something obviously needs to be changed...
,
Dec 15 2016
At the moment, the conclusion is that Chrome does what the specification instructs it to do and that your website is not coded according to the specification. The specification states that <iframe name="hidden"></iframe> overrides the document.hidden property and since jQuery (rightfully) uses document.hidden in order to stop, hold or completely omit animations while the tab is hidden, it gets a truthy value and therefore the animation is omitted. You could argue that jQuery could have protected itself from that situation by using - document.hidden === true Instead, however, since that property is supposed to be a boolean, there is no reason to do so, other than for being paranoid or overly protective (you could argue that jQuery should be overly protective, though, since it is used by billions of users). The "offending" line in jQuery - https://github.com/jquery/jquery/blob/master/src/effects.js#L452 You could - - File an issue with jQuery (or even submit a pull request) about document.hidden === true and update to the latest version once the code gets released. - Change your local version of jQuery to document.hidden === true (or override jQuery.speed in your own code, but that is too fragile, I believe). - Rename the iFrame. Note that your code may break at any time in other browsers, if they follow the specification (unless the specification changes and Chrome changes its implementation).
,
Dec 16 2016
yukishiino@ closing this as "working as expected" is fine, but for the browser interoperability, we can have more steps: - file bugs for other browsers so they follow the spec - file bugs or send PR for the spec clarification against WHATWG - etc. What we can do for developers is probably to advocate avoiding using the same name used as property names in Document for interoperability, as phistuck@ already commented above. |
|||||||||||||
►
Sign in to add a comment |
|||||||||||||
Comment 1 by drewcif...@gmail.com
, Nov 15 2016