New issue
Advanced search Search tips

Issue 888458 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Closed: Oct 25
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression

Blocking:
issue 895894



Sign in to add a comment

The HTML5 Drag element is not visible on page load

Reported by praveenh...@gmail.com, Sep 24

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36

Example URL:
Local webpage

Steps to reproduce the problem:
1. Local page when opened having HTML5 canvas elements 
2. the canvas elements are not loaded unless and play/pause of seek bar is clicked

What is the expected behavior?
When the HTML5 page is loaded the canvas elements should load and available to the user for drag and drop

What went wrong?
Canvas elements are not loading in version chrome 69 which was loading fine with the previous versions of the chrome browser 

Does it occur on multiple sites: Yes

Is it a problem with a plugin? N/A 

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 69.0.3497.100  Channel: stable
OS Version: 10.0
Flash Version:
 
Capture.PNG
30.1 KB View Download
Components: -Blink Blink>Canvas
Labels: Needs-Feedback
Would you provide a reproducible HTML please?

Labels: Needs-Triage-M69
I am afraid, i will not be able to share the page. But the page has been developed using HTML5. KonvaJS library, JQuery and Javacript.

When the page is loaded, the canvas drag elements will have to be loaded on the screen which user then can drag and drop in the square drop box.

This was possible in previous versions of chrome but in the current version of chrome (69) it is not possible.


Project Member

Comment 4 by sheriffbot@chromium.org, Sep 24

Cc: tkent@chromium.org
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: Needs-Feedback
We can't investigate this issue without a reproduction.  Can you make minimum reproduction, and attach it to this issue?

I have hosted the issue page having Drag and Drop in the below path:

https://securedownloads.excelindia.com/fordemo/ForDemo/sampleDnD/material/flash/Primary/Stage0/lesson0/unit0/main.html

Please check 
Project Member

Comment 7 by sheriffbot@chromium.org, Sep 28

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Is there any update on this?
Labels: Needs-Feedback
Reporter,
Would you explain what is the reproducible step, and what is expected behavior, and what's the actual behavior, with the excelindia.com URL please?

Steps to reproduce the problem:
1. open the URL shared https://securedownloads.excelindia.com/fordemo/ForDemo/sampleDnD/material/flash/Primary/Stage0/lesson0/unit0/main.html
2. You can seen the HTML5 drag and drop canvas elements which were suppose on load on page load are not loaded.

3. canvas elements are not loaded. As an alternate click on play/pause on the template of the URL shared and you can see now the elements are loaded

What is the expected behavior?
When the HTML5 page is loaded the canvas elements should load and available to the user for drag and drop

What went wrong?
Canvas elements are not loading in version chrome 69 which was loading fine with the previous versions of the chrome browser
Project Member

Comment 11 by sheriffbot@chromium.org, Oct 1

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: Needs-Feedback
> 1. open the URL shared https://securedownloads.excelindia.com/fordemo/ForDemo/sampleDnD/material/flash/Primary/Stage0/lesson0/unit0/main.html

We should click 'Start' button, right?

> 2. You can seen the HTML5 drag and drop canvas elements which were suppose on load on page load are not loaded.

Please describe what should be happen in the rendered page.  I saw "Drag and Drop activity", "Q: Attend the following drag and drop activity", and some boxes.  What's wrong with this rendering result?  We don't know what are drawn by <canvas>.

Please refer the document attached
Steps.docx
445 KB Download
Project Member

Comment 14 by sheriffbot@chromium.org, Oct 1

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Components: -Blink>Canvas Blink>Layout
Labels: -Type-Bug Needs-Bisect Type-Bug-Regression
Status: Untriaged (was: Unconfirmed)
Thank you for the information.

The CANVAS looks to have expected content, but it's not visible.  #container, which is an ancestor of the CANVAS, in the child IFRAME has 0-width.  This might be a layout issue.
Does it mean if the Iframe wide is set or increased the elements will be visible then?
I meant to say IFRAME width

Cc: swarnasree.mukkala@chromium.org
Labels: -Pri-2 -Needs-Bisect hasbisect-per-revision ReleaseBlock-Stable Triaged-ET Target-70 Target-71 RegressedIn-69 M-70 FoundIn-71 FoundIn-70 Target-69 FoundIn-69 OS-Linux OS-Mac Pri-1
Owner: junov@chromium.org
Status: Assigned (was: Untriaged)
Able to reproduce the issue on reported chrome version 69.0.3497.100 & on latest chrome 71.0.3567.0 using Windows 10, Ubuntu 17.10 and Mac 10.13.6. Hence providing bisect information below.

Bisect Info:
================
Good build: 69.0.3489.0
Bad build: 69.0.3491.0

CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+/f8b8872f2080130c2b5bdf026f32f46aad7598da

Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1134182

@Justin: Please confirm the issue and help in re-assigning if it is not related to your change.

Adding 'ReleaseBlock-Stable' label for M-70 as this is a recent regression. Please feel free to remove if this is not applicable.
Note: As there is no stable refresh in M-69, hence adding ReleaseBlock-Stable for M-70.

Thanks!
Owner: fs...@chromium.org
junov@ is no longer on Chrome.
[bulk edit] - This issue is marked as a stable blocker for M70. We are two weeks away from M70 Stable. Please take a look urgently!
Do let me know whether the chrome 69 will get any update/ revert any changes since the drag elements were appearing in the previous version of the chrome?

Comment 22 Deleted

We have explored and found that it is because of the CSS property "visible" is not applied from javascript in chrome browser, whereas if we use the other property "display" for hide and show, it is visible. 

Find the working sample using "display" property below:

https://securedownloads.excelindia.com/fordemo/ForDemo/sampleDND_display/material/flash/Primary/Stage0/lesson0/unit0/main.html

But we need the solution from the chrome browser, on why it is completely not supporting the "visible" property, which will affect the existing files that is in live.

Please provide the solution for this in your current/next version, for complete support of "visible" property in chrome browser.
Friendly ping! Could you please provide any update on this issue as it has been marked as a stable blocker.

Thank You!
Can we expect feedback and resolution for this any time sooner?
Cc: fs...@chromium.org
Components: Blink>CSS
Owner: e...@chromium.org
Status: Available (was: Assigned)
This seems to be a CSS/Layout problem, if it is so.
Labels: -ReleaseBlock-Stable
It was working fine with the previous versions of chrome and working fine with other browsers like edge and safari.

Can you recheck and confirm. Elements not displaying only after update to the chrome browser.
Cc: -tkent@chromium.org
Any update?
Any update?
Can I get to know any reason why this happened in latest version of chrome what what will be the update for this?
Components: -Blink>CSS -Blink>Layout Blink>Paint
Owner: chrishtr@chromium.org
I am able to repro this and re-bisected, also leading to the same range
as last time:

https://chromium.googlesource.com/chromium/src/+log/abb887f1fe0523ed4ab633530a3a55fd3e479731..a27b817c70dec1ea68f4ea4b8711697ca694fb62
Status: Assigned (was: Available)
Components: -Blink>Paint Blink>Compositing
Owner: vmp...@chromium.org
Vlad can you take a look to see if it is something in Blink compositing?
e.g. is the canvas layer present and sized correctly?
I can confirm that this is caused by https://chromium.googlesource.com/chromium/src/+/f8b8872f2080130c2b5bdf026f32f46aad7598da

but that _seems_ to have changed the timing a bit (for the better), so I'm still investigating the root cause
Findings so far:
- It seems that the call to draw image goes through as expected. There's nothing inherently wrong with the image since replacing the call to PaintCanvas with drawRect also doesn't appear (and correctly appears on the 'correct' page)
- Rebuilding the tree in the paint layer compositor also doesn't fix the issue

I will continue investigating on Monday.

It would be extremely helpful if there was a reduced case that demonstrated this issue (ie just one canvas with just one image that doesn't appear/appears). Either that, or a more detailed explanation of exactly what is happening with visibility/display properties on this page would be very helpful.
Please refer comment 23 section.

We have explored and found that it is because of the CSS property "visible" is not applied from javascript in chrome browser, whereas if we use the other property "display" for hide and show, it is visible. 
Cc: vmp...@chromium.org chrishtr@chromium.org
Components: -Blink>Compositing Blink>Layout
Owner: futhark@chromium.org
Here are the steps of what happens: 
There is a div in the iframe id="container", which has a single div child.
- At some point during loading we call removeChild on it, which removes the element and destroys the associated LayoutObject.
- Shortly after, we re-add that element. However, we don't seem to recompute the style on it (specifically we don't re-create the LayoutObject which was deleted), thus the parent 'container' div is judged to have no children and is 0 height.
- In dev tools, changing any style in the hierarchy will cause the style to recompute and recreate the LayoutObject which causes the drag-n-drop items to appear once again.

It does seem that we mark the parent chain as children needing style recalc, so I'm not sure what else is missing here. futhark@ do you mind looking at this further?
You don't happen to have a smaller repro?
Unfortunately, I couldn't repro with anything smaller. FWIW, the page isn't that big in terms of the layout tree :\
Components: -Blink>Layout Blink>Canvas
The problem is HTMLCanvasElement::FilterQuality() calling EnsureComputedStyle() on a dirty tree.

EnsureComputedStyle() is for constructing ComputedStyle in display:none subtrees of a clean tree. It was intended for getComputedStyle() which makes sure the ancestor chain is clean before calling EnsureComputedStyle(), but other instances which do not update style and layout tree first are potentially unsafe wrt clean/dirty bits. EnsureComputedStyle() should have a DCHECK for this.

futhark, what do you recommend we use instead of EnsureComputedStyle() ? I think this is was put there because we had cases where the style wasn't up to date when we needed it.
Document::UpdateStyleAndLayoutTreeForNode() followed by GetComputedStyle() should work.  Or, followed by EnsureComputedStyle if you need to get the computed style for display:none canvas elements. The question is if it's a (performance) problem to do a sync update where this method is called. I haven't looked at where FilterQuality() is called from. Ideally things relying on style and layout being clean should happen after or as part of the lifecycle update if possible.

Blocking: 895894
Cc: futhark@chromium.org
Owner: fs...@chromium.org
Status: Started (was: Assigned)
ok. on it.
Any updates?
Any updates?
Project Member

Comment 50 by bugdroid1@chromium.org, Oct 24

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/371eb5a301557fbbe2edcccad9ba7d4796c7d89b

commit 371eb5a301557fbbe2edcccad9ba7d4796c7d89b
Author: Fernando Serboncini <fserb@chromium.org>
Date: Wed Oct 24 18:08:39 2018

Update Document Style and Layout beforing getting style's filter quality

Bug:  888458 
Change-Id: Ib17eff8795d8daaa2e67f3c478f71079a52b9d5a
Reviewed-on: https://chromium-review.googlesource.com/c/1283488
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Fernando Serboncini <fserb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#602398}
[modify] https://crrev.com/371eb5a301557fbbe2edcccad9ba7d4796c7d89b/third_party/blink/renderer/core/html/canvas/html_canvas_element.cc

Labels: Merge-Request-71
Status: Fixed (was: Started)
This fixes the original bug. Please verify.
We may want to merge this to 71.
Labels: TE-Verified-M72 TE-Verified-72.0.3591.0
Able to reproduce the issue on reported chrome version #69.0.3497.100 using Ubuntu 17.10 as per comment#13.

Verified fix on latest chrome #72.0.3591.0 using Ubuntu 17.10, Mac OS 10.13.3 and Windows 10.
Attached screencast for reference.
Observed that when the HTML5 page is loaded the canvas elements got loaded, able to drag and drop the elements.
Hence adding verified labels.
Thanks.!
888458.mp4
1.9 MB View Download
Status: Assigned (was: Fixed)
Reopening: Could you merge into 71?
I requested it. 
It's a safe change to make.
Project Member

Comment 55 by sheriffbot@chromium.org, Oct 25

Labels: -Merge-Request-71 Hotlist-Merge-Review Merge-Review-71
This bug requires manual review: M71 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
This is regressed in M69 and M71 is currently in beta. Can't this wait until M72?
Labels: -Merge-Review-71
Status: Fixed (was: Assigned)
I think govind@ has a valid point.

This is a bit of a corner case, and since it was broken on 69, there's probably no reason why we can't wait another release.

Chris, did you have a particular reason to request merge here? I'll skip it for now, but feel free to reopen it.
Yes it regressed in M69, but it would nice to fix the regression 6 weeks earlier,
and I think the fix is safe.
Labels: Merge-Review-71
Adding "Merge-Review-71" based on comment #58.
Labels: -Merge-Review-71 Merge-Approved-71
Approving merge to M71 branch 3578 based on comment #58. Pls merge ASAP. Thank you.
Project Member

Comment 62 by bugdroid1@chromium.org, Oct 26

Labels: -merge-approved-71 merge-merged-3578
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/64a645fd89d4ba2d51c8b3642f0819c6383de5ec

commit 64a645fd89d4ba2d51c8b3642f0819c6383de5ec
Author: Fernando Serboncini <fserb@chromium.org>
Date: Fri Oct 26 14:15:14 2018

Update Document Style and Layout beforing getting style's filter quality

Bug:  888458 
Change-Id: Ib17eff8795d8daaa2e67f3c478f71079a52b9d5a
Reviewed-on: https://chromium-review.googlesource.com/c/1283488
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Fernando Serboncini <fserb@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#602398}(cherry picked from commit 371eb5a301557fbbe2edcccad9ba7d4796c7d89b)
Reviewed-on: https://chromium-review.googlesource.com/c/1301836
Reviewed-by: Fernando Serboncini <fserb@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#345}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}
[modify] https://crrev.com/64a645fd89d4ba2d51c8b3642f0819c6383de5ec/third_party/blink/renderer/core/html/canvas/html_canvas_element.cc

Labels: Merge-Merged-71-3578
The following revision refers to this bug: 
https://chromium.googlesource.com/chromium/src.git/+/64a645fd89d4ba2d51c8b3642f0819c6383de5ec

Commit: 64a645fd89d4ba2d51c8b3642f0819c6383de5ec
Author: fserb@chromium.org
Commiter: fserb@chromium.org
Date: 2018-10-26 14:15:14 +0000 UTC

Update Document Style and Layout beforing getting style's filter quality

Bug:  888458 
Change-Id: Ib17eff8795d8daaa2e67f3c478f71079a52b9d5a
Reviewed-on: https://chromium-review.googlesource.com/c/1283488
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Fernando Serboncini <fserb@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#602398}(cherry picked from commit 371eb5a301557fbbe2edcccad9ba7d4796c7d89b)
Reviewed-on: https://chromium-review.googlesource.com/c/1301836
Reviewed-by: Fernando Serboncini <fserb@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#345}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}
Thanks!
As per my understanding this fix will be updated in Chrome version 71.

Is that correct? If so, when will the chrome 71 version rolling out?
Chrome 71 will be in Beta starting Nov 1st.
Full stable release scheduled for Dec 4th.

M71 is already in beta as of last Thursday, 10/25.
We checked installing the Chrome version 71, but still the same issue exists.

Refer the attachment for the same.

Please confirm.
Notfixed_version71.PNG
62.2 KB View Download
Labels: TE-Verified-71 TE-Verified-71.0.3578.30
Able to reproduce the issue on reported chrome version #69.0.3497.100 using Windows 10 as per comment#13.

Verified fix on latest chrome #71.0.3578.30 using Ubuntu 17.10, Mac OS 10.14 and Windows 10.
Attached screencast for reference.
Observed that when the HTML5 page is loaded the canvas elements got loaded, able to drag and drop the elements.
Hence adding verified labels.
Thanks.!
888458_M71.mp4
1.9 MB View Download
Thank you. Able to see the issue fixed in beta version of Chrome.

Hope the same will be updated in stable version of Chrome also.

Sign in to add a comment