Last Comment Bug 635988 - page showing html5 youtube video focus the video and scroll it into view
: page showing html5 youtube video focus the video and scroll it into view
Product: Core
Classification: Components
Component: Event Handling (show other bugs)
: Trunk
: All All
-- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Andrew Overholt [:overholt]
: 637177 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2011-02-22 13:58 PST by Ed Lee :Mardak
Modified: 2013-12-27 14:19 PST (History)
13 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

iframe to youtube with lots of margin-top (180 bytes, text/html)
2011-02-22 13:58 PST, Ed Lee :Mardak
no flags Details
minified test case (296 bytes, text/html)
2011-02-22 17:17 PST, Ed Lee :Mardak
no flags Details

Description User image Ed Lee :Mardak 2011-02-22 13:58:31 PST
Created attachment 514305 [details]
iframe to youtube with lots of margin-top

When Google Reader loads a new article, sometimes the page jumps down to some random-ish location. Turns out it's somehow caused by embedding a youtube video in an iframe (using the standard youtube embed code).

The bottom of the page scrolls to the very top of the video, so you see the article just before the video in Reader.

This seems to only happen when the fallback to <video> is used instead of flash, which seems to be the default behavior in Google Reader.

I've regressed it back to 0804 - 0805: bbefb7bcb41e

That might point to bug 581848? But that's probably just covering the real issue.?

The attached is just an iframe with a lot of scroll:

<iframe title="YouTube video player" width="640" height="390" src="" frameborder="0" allowfullscreen style="margin-top: 10000px;"></iframe>

To get it to scroll, Flash needs to be *disabled* in this case, but leaving flash enabled or disabled will cause Reader to scroll
flash is *disabled* and
Comment 1 User image Ed Lee :Mardak 2011-02-22 14:02:20 PST
Oh, this also happens when you have the html5 youtube trial enabled:

Just load the testcase and it'll jump to show a blank page just above the video.
Comment 2 User image Ed Lee :Mardak 2011-02-22 14:06:51 PST
Fyi, loading the testcase in Chrome 10.0.648.82 beta doesn't jump to the video when disabling all plugins (or just disabling flash).

Flash version for reference even though it needs to be disabled for this to happen:

Happens on trunk and since beta 3 or so.
Comment 3 User image Ed Lee :Mardak 2011-02-22 15:08:03 PST
This happens on windows as well. I'll see if I can find a better range on my windows machine. Probably not a plugin issue as it happens when the plugin is disabled. ?
Comment 4 User image Ed Lee :Mardak 2011-02-22 17:15:23 PST
Not quite sure where to file this or if this is by design, but basically the youtube iframe is calling focus() on a div with tabindex and that causes the parent page to scroll.
Comment 5 User image Ed Lee :Mardak 2011-02-22 17:17:35 PST
Created attachment 514374 [details]
minified test case

Basically does:

<iframe src="focus a div" style="margin-top: 10000px;"></iframe>

And "focus a div":

<div id="d" tabindex="0"></div>
<script>addEventListener("DOMContentLoaded", function() {
}, false)</script>

This doesn't scroll in Safari 5.0.3 (6533.19.4) or Chrome 10.0.648.82 beta or Opera 11.01.
Comment 6 User image Ed Lee :Mardak 2011-02-22 17:24:33 PST
Fyi, if you change "div" to "input", Chrome and Safari scroll while Opera doesn't scroll (but does move focus, so if you type, it'll jump to the input box).
Comment 7 User image Ed Lee :Mardak 2011-02-22 17:45:41 PST
I spotted bug 606011 when looking for dupes or related bugs, and decided to test that in other browsers as well.

Generally it seems like other browsers will *not* scroll to .focus()ed elements that have no content, e.g., empty div or anchor with no content. I believe the YouTube div#video-player node has content, so I'm not quite sure what their heuristics are to determine when to scroll or not.
Comment 8 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2011-02-22 21:34:00 PST
Is this a regression?

I suspect Ehsan, whether it is or not :-)
Comment 9 User image Ed Lee :Mardak 2011-02-22 22:54:28 PST
Not a regression. I just checked 3.6, 3.5, 3, 2, 1.5. Only 1(.0.8) didn't scroll and that was because "Error: document.getElementById("d").focus is not a function"

Probably not a blocker depending on how aggressively Google will switch to html5 video by default. But hopefully by then, they'll have removed/worked around this <div tabindex="0">.focus() issue. [The other STR is probably less likely with the user disabling Flash and YouTube falling back to <video>.]

Otherwise any page using the default embed code provided by YouTube will result in the page jumping around in Firefox only. (This is especially bad on blogs that embed a video in each post as Firefox will seem like it's spazzing out. o.O)

Do we have a way to file bugs against YouTube or at least poke people? (Any suggestions for a workaround?)
Comment 10 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2011-02-22 23:54:42 PST
We can send email to mozilla-google-discuss.

However, for the sake of interop we should probably a) make sure the HTML spec says whether to scroll or not and b) implement whatever the spec says.
Comment 11 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2011-02-22 23:56:38 PST
I'd be particularly interested to hear from Neil whether he thinks we should be focusing the div and scrolling it into view in this case.
Comment 12 User image Mike Beltzner [:beltzner, not reading bugmail] 2011-02-23 11:30:17 PST
Not going to block, but yes, please make sure it ends up on mozilla-google-discuss, follow up on spec, and renominate if it becomes a bigger issue in the future!
Comment 13 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2011-02-23 13:35:17 PST
The spec doesn't seem to say anything about scrolling elements into view when they're focused.

My inclination would be to always scroll elements into view when they're focused, because that's the simplest behavior, but I still want to hear to Neil thinks.
Comment 14 User image Christopher Blizzard (:blizzard) 2011-02-23 15:00:03 PST
Added Ed to the list.
Comment 15 User image :Ehsan Akhgari 2011-02-23 19:40:43 PST
Unassigning now that my name is cleared from this!  ;-)
Comment 16 User image Ed Lee :Mardak 2011-02-24 09:34:43 PST
You can add 's feed to Google Reader or just visit that page to see stuff jump around.
Comment 17 User image Asa Dotzler [:asa] 2011-02-27 10:54:37 PST
If bug 637177 is a duplicate of this, it's considerably more widespread than Google Reader. I see it on and and various other sites.
Comment 18 User image Asa Dotzler [:asa] 2011-02-27 10:59:50 PST
I cleared my YouTube cookies (one of them presumably the HTML5 video opt-in) and now I'm no longer getting the scrolling behavior at the IE blog or Tantek's site. I'll dupe my bug here.
Comment 19 User image Asa Dotzler [:asa] 2011-02-27 11:01:29 PST
*** Bug 637177 has been marked as a duplicate of this bug. ***
Comment 20 User image Neil Deakin 2011-02-28 07:23:56 PST
IE9 scrolls to empty content when focused.

Safari/Chrome appear to be using a more complex heuristic that depends on how visible the element is. The following, for example, does not scroll, despite that the text overflows and is visible to the user:

<div id="d" tabindex="0" style="width:0px; height: 0px;">Cats</div>

Presumably, some form of 'is zero-rectangle' check is performed before scrolling. Note also that element.scrollIntoView() does scroll on collapsed elements even when focus() does not.

It doesn't seem to me that there should be a reason not to scroll to empty elements, especially as this one has a explicit tabindex set.
Comment 21 User image Ed Lee :Mardak 2011-02-28 08:36:40 PST
YouTube will be removing the call to focus(). It breaks other things as well in other browsers like keyboard shortcuts in Reader.
Comment 22 User image Ed Lee :Mardak 2011-03-07 14:19:45 PST
Seems to be fixed today.

Note You need to log in before you can comment on or make changes to this bug.