ps: behaviour was working correctly up to Chrome 54, no more in Chrome 55

Able to reproduce this issue on Windows-10, Mac OS 10.12 and Ubuntu 14.04 using chrome latest stable M55-55.0.2883.87 by following steps mentioned in the original comment.

Good build:55.0.2861.0
Bad build: 55.0.2863.0

Using the per-revision bisect providing the bisect results,

You are probably looking for a change made after 418855 (known good), but no later than 418856 (first known bad).

CHANGE-LOG URL:
---------------------------------------
https://chromium.googlesource.com/chromium/src/+log/2525299ceb48722a1271c8c7e8ae1bbd8aa724e3..6d73ab5ed5d9b00bc48da255dc6599e90e72f599

From the CL above, assigning the issue to the concern owner
Review-Url: https://codereview.chromium.org/2339653003

sunyunjia@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Note: Adding RB-Stable, since this issue is observed on M-55, M-56 & M-57. Please feel free to edit if this is not the case.

Thanks!

Can I ask for a minimized test case for this bug? The javascript in the provided link is a bit complicated for us to triage the problem. Thanks!

The issue appears to be that the page focuses this invisible <div>:

<div tabindex="0" hidefocus="true" role="tree" style="font-size: 0px; position: absolute; outline: 0px; z-index: -1; left: 0px; top: 0px;">
    <input type="text" tabindex="-1" role="presentation" style="opacity: 0; height: 1px; width: 1px; z-index: -1; overflow: hidden; position: absolute;">
</div>

However, it appears this <div> has no width/height and no position - so where as previously we would ignore the scrollIntoView that occurs when we focus it, sunyunjia@'s patch fixed it so that we "pretend" it has 1x1 size (this fixes  issue 646738 ) which causes the scroll back to top.

It seems in Edge and Firefox, the <div> is sized and positioned when an item is clicked so the real bug here is that's not happening on Chrome. The patch in #3 only reveals the bug so this might not actually be a regression.

Unfortunately I don't know GWT so I don't know how to debug this further. It could be a separate bug in Chrome, a bug in GWT or UA sniffing that should be removed.

awalter.2308@: Does GWT go through a processing step? Could you provide the unprocessed source to the example?

do you mean the source code of the tree as java project in GWT. I can send you if it helps you

I am not exactly aware of the exact processing steps in GWT.
What we do know is that it was handled correctly in earlier Chrome version, we use those trees for at least 3 years now. So I am very sure that it is not a GWT bug.

Yes, the java project in this case would help.

It's possible there's an issue in GWT even if it worked before, just that it was masked by the bug that was fixed by  issue #3 . More likely, GWT might be doing something intentially to work around a Chrome bug/quirk that was fixed.

attached the complete sample project. It is a maven 3 project, build on GWT 2.8 and JDK 8.

Deleted: SampleToDemonstrateTheTreeBug.zip 51.5 KB

SampleToDemonstrateTheTreeBug.zip 51.5 KB Download

With respect to the label added: Needs-triage-Mobile, triaged the issue and below are the observations.

Able to reproduce the issue on Mobile device (Tablet and Handset) with the test URL provided.

Devices Used:
=============
Device name: Nexus 6P (Handset)
Chrome version Used: Dev - 57.0.2984.3
Android Version: 7.1.1 / NMF26X

Device name : Samsung Galaxy Tab S2 (Tablet)
Chrome version Used: Dev - 57.0.2986.0
Android Version: 6.0.1 / MMB29K 

Observations on Mobile Device: 
===============================
1) Loaded the URL " https://www.apartment-baden.com/test/
2) Tapped on the tree items being visible on load of page, observed the popup
3) Scrolled down and clicked on the tree item, observed that the page scrolled up.

P.S: Also tried by checking the option "Request desktop site", same behavior was observed. Adding OS android as well.

Just to update the latest behavior issue is still observed on Ubuntu 14.04 using chrome latest Dev M58-58.0.3000.4.

sunyunjia@ - Since this issue is marked as RB-Stable, could you please let us know is there any latest update available on this issue?

Thanks!

A friendly reminder that M57 Stable is launch is coming soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

Just to update the latest behavior of this issue, Able to reproduce it on Windows-10 using chrome latest canary #58.0.3012.0. 

sunyunjia@ We're getting closer to M57 early stable launch and this issue is marked as RB-Stable, so can we get any latest update on this issue? 

Thanks!

As we looked further into the JavaScript code, this is not a regression.

- Set a breakpoint in line 6750 of test-0.js
- This line reads offsetWidth and height from an element in the tree
- Chrome incorrectly returns 0 for both these values
- this causes us to position the focusable element at 0,0
- later when calling focus on that element chrome scrolls up since the element is now at 0,0

And Chrome has been incorrectly returning 0 since M53.0.2785.0. So this is a historic problem, we should probably assign it to layout team.

A friendly reminder that M57 Stable is launch is coming VERY soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch (2987) ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

As per comment #15 adding layout component for more updates on this issue. Could any one from layout team look in to it?

Thanks!

sunyunjia@: do we know why the element gets offsetWidth/Height 0? i.e. what about the way the element is created gives it the 0 width/height? Could you create a self-contained page that reproduces the issue? That'll make it much easier for someone from the layout team to diagnose and fix the issue.

This bug exists since M55. So punting to M58 as there isn't a fix yet. Please let me know if anyone has any concern here. Thank you.

Here is a minimized case for the bug. Notice the outer div that has id="1" and display: inline. When inspecting this element in Firefox, it has correct offsetWidth and offsetHeight. However, when inspecting this element in Chrome, both the offsetWidth and offsetHeight are zero.

Could anyone from layout team look into it？

Deleted: tree1.html 66 bytes

tree1.html 66 bytes View Download

I can't find anything in the spec to suggest whether an inline box with only block children should take up space or not.

Tab/Ian could either of you comment on this please? 

Also, why is this marked as a release blocker? We've had this behavior for *years*. Changing it will likely break a lot of content.

Actually adding Tab and Ian this time.

Tab/Ian: could either of you comment on whether inlines containing only block children should have a size or not? I can't find anything in the spec to suggest either behavior.

It was RBS because we changed how scrollIntoView treats boxes without a size (to match Firefox) and this caused a change in behavior. But yah, the layout issue shouldn't be RBS and the scrollIntoView change should stick unless we find significant breakage so removing the label.

The tree view works fine not only in Firefox, also in Internet Explorer, Microsoft Edge and Mac Safari. And Chrome could handle it correctly up to M53. Maybe it helps to compare the stack traces of M53 working to latest M57 to see what is the difference? Or the Edge dev tools output DOM. Thank you!

Ping. Tab/Ian, any thoughts?

you may close this issue, we could resolve it with help of GWT support

https://github.com/gwtproject/gwt/issues/9475

In GWT class generating the tree, one has to override  set fous method and trigger no activity:
@Override
public void setFocus(boolean focus)
{ // Don't do anything }