New issue
Advanced search Search tips

Issue 898843 link

Starred by 2 users
Status: Available
Owner: ----
Cc:
chaopeng@chromium.org
bokan@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows
Pri: 3
Type: Bug



Sign in to add a comment

window.location.hash on iframe causes a top offset on top window body

Reported by aymericd...@gmail.com, Oct 25 
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0

Steps to reproduce the problem:
1. Style the "html" and "body" tags with "height:100%"
2. Add an iframe in the body
3. From the iframe, change the window.location.hash to anything

What is the expected behavior?
Changing "window.location.hash" should not have any consequences on the the position of the body from the parent's window.

What went wrong?
The position of the parent's window body is moved to several pixels to the top.
The 'top' position returned by "getBoundingClientRect" goes from 8px to -2px in the attached example.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 70.0.3538.67 (Build officiel) (64 bits) (cohort: 70_67_Win)  Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 31.0 r0
index.html
210 bytes View Download
frame.html
561 bytes View Download

Comment 1 by aymericd...@gmail.com, Oct 25 

After several tests, it seems it not only depends of the "html"/"body" height but any parent. If we set a "height" in pixel or percentage at any parent level, then the bug happens. If we use "height:auto" it doesn't happen.
index.html
284 bytes View Download

Comment 2 by dtapu...@chromium.org, Oct 25

Components: Blink>Scroll

Comment 3 by phanindra.mandapaka@chromium.org, Oct 25

Labels: Needs-Triage-M70

Comment 4 by bokan@chromium.org, Oct 25

Cc: bokan@chromium.org
Labels: OS-Linux
Owner: chaopeng@chromium.org
Status: Assigned (was: Unconfirmed)
Reproduced on Linux 71.0.3573.0. Chao, ptal.

Comment 5 by bokan@chromium.org, Oct 25 

Also, repro is hosted at: http://bokand.github.io/bugs/898843/index.html

Comment 6 by chaopeng@chromium.org, Oct 29 

This behavior is because:

We call scrollIntoView when navigating to url fragment. when the fragment is empty it selected the <html> of <iframe> which offset is 10. 8px margin for top frame and 2 pixel for iframe border.

There are 2 questions here:

1. Should window.location in iframe recursing up the containing block chain?
2. Should we treat invalid hash as empty hash?

For Question 1:

I can not tell which behavior is correct or better.

1. the spec never mention window.location should not recuse up the containing block chain
2. in the test page, try giving the iframe margin-top = 500px, chrome can still move the iframe element to top of page, but firefox can not. Also try to make the iframe scrollable, recuse up scrolling seems better http://ht.chaopeng.me/898843/index.html

http://w3c.github.io/html/browsers.html#navigating-to-a-fragment-identifier

For Question 2:

In the test page aymericdmdv@ giving, #test is invalid hash, but we did the scrolling because we treat invalid hash is different than empty hash. Maybe we should fix this case.

Comment 8 by bokan@chromium.org, Oct 29

Cc: chaopeng@chromium.org
Labels: -Pri-2 Pri-3
Owner: ----
Status: Available (was: Assigned)
Thanks for the investigation.

> 2. Should we treat invalid hash as empty hash?

From the spec, an empty hash means "top of document" is the indicated part whereas an invalid hash means no indicated part. So I think that part of it is fine. spec: https://html.spec.whatwg.org/multipage/browsing-the-web.html#the-indicated-part-of-the-document

> 1. Should window.location in iframe recursing up the containing block chain?

The spec is vague about this. Safari also recursively scrolls the element into view while Edge and Firefox do not.

So it's not clear what the "correct" behavior is. I'm not against changing to match Firefox and Edge as I actually think that behavior seems more intuitive to me, but I don't think this is a priority for us.
►

Sign in to add a comment