The HTML5 Drag element is not visible on page load
Reported by
praveenh...@gmail.com,
Sep 24
|
||||||||||||||||||||||||||||||||
Issue descriptionUserAgent: 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:
,
Sep 24
,
Sep 24
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.
,
Sep 24
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
,
Sep 25
We can't investigate this issue without a reproduction. Can you make minimum reproduction, and attach it to this issue?
,
Sep 28
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
,
Sep 28
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
,
Sep 30
Is there any update on this?
,
Oct 1
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?
,
Oct 1
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
,
Oct 1
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
,
Oct 1
> 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>.
,
Oct 1
Please refer the document attached
,
Oct 1
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
,
Oct 1
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.
,
Oct 1
Does it mean if the Iframe wide is set or increased the elements will be visible then?
,
Oct 1
I meant to say IFRAME width
,
Oct 1
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!
,
Oct 1
junov@ is no longer on Chrome.
,
Oct 1
[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!
,
Oct 2
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?
,
Oct 4
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.
,
Oct 4
Friendly ping! Could you please provide any update on this issue as it has been marked as a stable blocker. Thank You!
,
Oct 5
Can we expect feedback and resolution for this any time sooner?
,
Oct 5
This seems to be a CSS/Layout problem, if it is so.
,
Oct 5
,
Oct 6
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.
,
Oct 9
,
Oct 9
Any update?
,
Oct 10
Any update?
,
Oct 11
Can I get to know any reason why this happened in latest version of chrome what what will be the update for this?
,
Oct 11
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
,
Oct 11
,
Oct 12
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?
,
Oct 12
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
,
Oct 12
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.
,
Oct 13
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.
,
Oct 15
Single D&D is provided in the below path: https://securedownloads.excelindia.com/fordemo/ForDemo/sample_singleDnD/material/flash/Primary/Stage0/lesson0/unit0/main.html Please check and let me know.
,
Oct 15
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?
,
Oct 15
You don't happen to have a smaller repro?
,
Oct 15
Unfortunately, I couldn't repro with anything smaller. FWIW, the page isn't that big in terms of the layout tree :\
,
Oct 16
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.
,
Oct 16
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.
,
Oct 16
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.
,
Oct 16
,
Oct 16
ok. on it.
,
Oct 20
Any updates?
,
Oct 24
Any updates?
,
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
,
Oct 24
This fixes the original bug. Please verify. We may want to merge this to 71.
,
Oct 25
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.!
,
Oct 25
Reopening: Could you merge into 71?
,
Oct 25
I requested it. It's a safe change to make.
,
Oct 25
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
,
Oct 25
This is regressed in M69 and M71 is currently in beta. Can't this wait until M72?
,
Oct 25
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.
,
Oct 26
Yes it regressed in M69, but it would nice to fix the regression 6 weeks earlier, and I think the fix is safe.
,
Oct 26
Adding "Merge-Review-71" based on comment #58.
,
Oct 26
Approving merge to M71 branch 3578 based on comment #58. Pls merge ASAP. Thank you.
,
Oct 26
,
Oct 26
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
,
Oct 26
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}
,
Oct 26
Thanks!
,
Oct 30
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?
,
Oct 30
Chrome 71 will be in Beta starting Nov 1st. Full stable release scheduled for Dec 4th.
,
Oct 30
M71 is already in beta as of last Thursday, 10/25.
,
Oct 31
We checked installing the Chrome version 71, but still the same issue exists. Refer the attachment for the same. Please confirm.
,
Oct 31
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.!
,
Nov 2
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 |
||||||||||||||||||||||||||||||||
Comment 1 by tkent@chromium.org
, Sep 24Labels: Needs-Feedback