Status Update
No update yet.
Comments
sa...@chromium.org
[Empty comment from Monorail migration]
sa...@chromium.org
@alex.popov: Thanks for the report!!
This issue seems to be a dupe ofhttps://crbug.com/chromium/767388 . Hence merging into this issue, please feel free to undo if not the case.
Thanks!!
This issue seems to be a dupe of
Thanks!!
[Deleted User] <[Deleted User]>
Hi Sandeep, thanks for the feedback.
I think the issue is related but is not a duplicate.
Note that there are significant additional issues reported here that are outside the scope of of 767388 that are not resolved by the use of the new VisualViewport API (as recommended in 767388). These issues are:
1. Element geometry (getBoundingClientRect) is inaccurate.
2. Intersection observer calculations are inaccurate.
3. Scroll position is not calculated correctly.
Therefore I think this warrants reviewing and hopefully addressing independent of 767388.
I think the issue is related but is not a duplicate.
Note that there are significant additional issues reported here that are outside the scope of of 767388 that are not resolved by the use of the new VisualViewport API (as recommended in 767388). These issues are:
1. Element geometry (getBoundingClientRect) is inaccurate.
2. Intersection observer calculations are inaccurate.
3. Scroll position is not calculated correctly.
Therefore I think this warrants reviewing and hopefully addressing independent of 767388.
[Deleted User] <[Deleted User]>
Hi Sandeep, any updates on the above? It seems like we should reopen this issue because it reports additional breaking behavior and is not resolved by the workarounds suggested in the other issue.
is...@google.com
This issue was migrated from crbug.com/chromium/842863?no_tracker_redirect=1
[Monorail mergedinto:crbug.com/chromium/767388 ]
[Monorail components added to Component Tags custom field.]
[Monorail mergedinto:
[Monorail components added to Component Tags custom field.]
Description
See attached test app (build from source).
The app consists of a single WebView that loads some simple HTML within the WebView.
This HTML page shows a bug in how the WebView calculates the dimensions of the window (innerHeight
and innerWidth) and the coordinates of the elements relative to the window perhaps as a sideeffect.
1. innerWidth and innerHeight: the width and height of the WebView are natively hardcoded to be
360dp x 400dp. Yet innerWidth and innerHeight will report significantly larger values.
2. scrollY is frozen at a value of 0 even after scrolling in the WebView until a certain point is
reached (did not investigate at WHAT point exactly) and then starts incrementing. Note scrollY
does not exceed 0 until well after the red <div> is scrolled completely out of the viewport.
3. Related to 2, getBoundingClientRect() on the <img> element returns incorrect values that do not
update as the viewport is scrolled.
4. IntersectionObserver is broken as a result. Notice it does not update as we scroll through the
WebView and the position of the <img> element changes.
The above can be confirmed by attaching an inspector to the WebView.
This issue appears to be related to
What is the expected behavior?
The scroll position and coordinates should be reported correctly.
What went wrong?
The expected behavior is not met.
Did this work before? N/A
Does this work in other browsers? Yes
Chrome version: 66.0.3359.158 Channel: stable
OS Version: 7.0
Flash Version: N/A