Rotation transform breaks overlap detection in compositing decisions
Reported by
eric.mel...@wandcorp.com,
Sep 21
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.16 Safari/537.36 Platform: 10895.56.0 (Official Build) stable-channel veyron_fievel Steps to reproduce the problem: 1. create a HTML document with a video tag at z-index 1 2. create other HTML elements in the body at same z-index 3. display this in a packaged app What is the expected behavior? the HTML will be read top to bottom with elements at the same index display on top based on the order the elements are in the body. What went wrong? Video elements are always on top, irrelevant of their location in the body. to not display a video element on top of on top HTML elements it needs to located at a lower z-index. Did this work before? Yes R68 Does this work in other browsers? Yes Chrome version: 69.0.3497.95 Channel: stable OS Version: Flash Version: z-index 0 no longer appears as valid either.
,
Sep 25
,
Oct 3
Technical case created with #17103662 I've requested an update directly to support engineers.
,
Oct 4
There is a difference between browser and extension picture, but I don't see difference between v66-v68-v69 extension picture, so cannot confirm it's regression. If there is an example on v68 - please provide a video.
,
Oct 5
This demonstrates R68 to R69 in a kiosk application.
,
Oct 5
Thank you for your response Eric. We'll be reviewing the information and get back to you soon.
,
Oct 5
I have confirmed a number of things. - Extensions have had this issue at least as far back as R57 - Browser has never had this issue all the way to R70 - Kiosk packaged applications did not have this issue in R68 - Kiosk packaged applications do have this issue in R69 So this is a long running issue in extensions that was applied to kiosk applications in the R69 release. Since our testing is with the kiosk application, we did not notice extensions have this issue for a very long time.
,
Oct 5
,
Oct 11
Greetings team. We'd like to confirm if this issue is being handled as a bug on this platform as the technical case in Google Cloud Support is left dormant waiting for an update here. If any further data is required let us know.
,
Oct 17
@mknowles: Could you help the Support team triage this bug? The issue started in M69, M68 did not have this issue, and Chrome browser was able to render the page correctly all the way to M70.
,
Oct 18
This appears to be a layout issue, so sending this to the layout team to Triage further.
,
Oct 21
Over to apps team as this only happens in package apps, as per description. I suspect package apps have custom styling that interfers with z-index.
,
Oct 25
Team, is there any work on this issue? Our customer is highly impacted by this problem and we don't have any updates about a fix ETA. Can you please advise?
,
Oct 29
dominickn, are you able to identify a resource to take a look at this issue?
,
Nov 8
,
Nov 8
Hi all is there any updates on this?
,
Nov 8
I'm not the right person to look into this. Ben?
,
Nov 8
Sorry about the bouncing around so much. I'm going to pass this on to raymes@ who is looking after packaged apps. Raymes - there has possibly been some change to the app specific custom styling. Let me if you want any pointers. Also adding Drew Wilson who might have more resources to investigate.
,
Nov 16
Hello team, Is there any updates about this?
,
Nov 18
,
Nov 19
atwilson: since this regressed in kiosk mode, I think the easiest way to track it down would be to bisect kiosk mode (even though it may be a broader issue). Is this something your team can help with? I'm not really set up to do that right now.
,
Nov 19
Sounds like this happens with packaged apps in general (not just kiosks?) +kathrelkeld who may be able to help with bisecting
,
Nov 19
Issue is present in extensions as far back as M57 Was just introduces into Kiosk apps in M69 So yes, happens in all packaged apps.
,
Nov 19
Marcus, can you help us get resources together to perform a bisect - looks like a rendering issue has recently started regressing in kiosk apps (existed outside of kiosk sessions previously).
,
Nov 19
atwilson: is it possible to simulate a kiosk mode session on Chrome OS on linux? If so, it would be simple to bisect and I'm happy to do it.
,
Nov 23
add #24 - handing over to alex as Kiosk PM
,
Nov 29
Can a extension not be bi-sected? Same bug is present in extensions, just far older. True this bug is for the kiosk mode, but not exclusive to it.
,
Dec 4
,
Dec 4
,
Dec 4
Dear team, Just a friendly reminder. This bug has been raised on the 21st of September by our Enterprise customer whose business is directly impacted by this issue. We are the 4th of December and our Enterprise customer would expect it to be assigned... -> Would it be possible to have it assigned? -> If the investigation is done in another bug could we mark this one as dup as mentioned in crbug.com/888040#c23? -> Do you need additional information from the customer, that could help for the investigation? Thank you in advance for your help.
,
Dec 4
I'd still like to get help if possible from someone who has worked on kiosk mode to bisect the bug. That would help narrow things down a lot.
,
Dec 5
,
Dec 5
,
Dec 5
Hi Eric, I have tried using the .crx file provided in #c1 and added to chrome://extensions. "ERR_FILE_NOT_FOUND" error shown on launching the Demo extension. Could you provide a working .crx file to reproduce the issue ?
,
Dec 5
I just loaded the .crx on my desktop without issue. Perhaps if package it yourself, I am including a zip with the files. You will see there is nothing to it, its just a simple index.html with a video background. I see no reason it wouldn't work.
,
Dec 5
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
,
Dec 6
Update: I have a kiosk setup running so I should be able to bisect early next week.
,
Dec 6
Issue is reproducible on M69 and M68, below are the checked versions 10895.48.0 69.0.3497.85 stable 10895.33.0 69.0.3497.58 beta 10895.20.0 69.0.3497.33 beta 10895.10.0 69.0.3497.21 dev 10718.88.2 68.0.3440.118 stable For the first app launch, text shown for a second and disappears. Text is not displayed for following app launches. Attached logs and screenshot.
,
Dec 6
Bug seen on M67(67.02296.99,10575.58.0) as well. video - https://drive.google.com/file/d/105s06lt9ipVoUkjvsl6GaQbkpKAAw3rn/view
,
Dec 11
Bisecting kiosk, I didn't find evidence that this worked in older versions of Chrome in my setup. I also bisected further on desktop and couldn't find a version where this worked correctly in packaged apps. I'm going to look into the code a bit.
,
Dec 11
So this issue is due to the custom styling in platform_app.css: https://cs.chromium.org/chromium/src/extensions/renderer/resources/platform_app.css?q=platform_app.css&sq=package:chromium&dr This gets applied to all platform apps. As far as I can tell, it's not a regression and has always been the way things work in packaged apps. My understanding is that setting "overflow: hidden" on the html tag somehow triggers the <video> element to be stacked in a different way to how it would otherwise. You can reproduce this on the web by adding: html { overflow: hidden; } to the top of style.css in the app. There's no indication that this is a bug on the blink side since stacking order computation is quite complicated and impact by seemingly unrelated things (see e.g. https://philipwalton.com/articles/what-no-one-told-you-about-z-index/). Setting overflow: hidden is intentional in platform apps so that they don't get scrollbars by default. I don't think we're likely to change this behavior. I would suggest that the best thing to do is work around the issue by setting a position on the <video> element and explicitly set its z-index. Let us know if that's not feasible for some reason, but for now I'm closing as WontFix based on the above.
,
Dec 11
While I respect this conclusion. I did show above in "Comment 5" the issue not present in Kiosk Mode on R68 release. I believe, a packaged app in extension versus a packaged app in single app kiosk use a different picture. The fact that we have our entire population of kiosk devices locked at R68 currently because R69 will introduce this issue, is absolute proof to me and completely disputes the findings. Overflow hidden intentional doesn't help with a webpage inside the packaged app, only with the actual packaged app. Removing this doesn't actually change anything anyways. The application we reported this for displays web pages inside the application as a content management system. Most users rotate a web page as opposed to rotating the the device orientation, so this will impact many hundreds of users, and create a liability for the need to re-code existing HTML content. This is of extreme impact still, as the issue was not present before R69 and is not present when working in chrome browser. While your reasoning make sense to me.. this will make no sense to anyone else. I do concede the issue has been present in packaged apps run as an extensions for most likely several years. But, stating this has been like this in single kiosk manged applications is entirely incorrect.
,
Dec 11
Just to really finalize what I am saying here, I have attached 2 images. Both are images of the same packaged extension. First image is rotated a 60 degrees. Second image is rotated at 61 degrees. The text disappears from the its correct stack location at 61 degrees. It has nothing else changed. Only 1 degree of rotation causes this bug do demonstrate itself.
,
Dec 13
> Overflow hidden intentional doesn't help with a webpage inside the packaged app, only with the actual packaged app. I'm not sure exactly what you mean by this? > This is of extreme impact still, as the issue was not present before R69 and is not present when working in chrome browser. In my setup, there wasn't a change between 68 and 69. As I mentioned I couldn't find the bug by bisecting. See my attached zip. If you open index.html in a regular tab, you will notice the issue is reproduced. If you go into style.css and remove the top line, you will see that it fixes it. Basically in a packaged app that line is silently inserted into all html content loaded, which is intended. If there is a bug here, it would be a layout issue, which it may well be because firefox displays the page as you want it to be displayed. Layout team: could you please take a look at index.html in the attached zip. It displays differently in FF and Chrome.
,
Dec 13
,
Dec 13
Thanks for looking at this again. I would like to change the issue header, as this scope of this has changed significantly. Elements that contain video elements can't be rotated more then 89deg, or they will not display correctly. - I can remove all css including overflow and this behavior continues. - This is run as a Chrome packaged application in the Chrome Shell - This issue is demonstrated in the attached video a bit more clear then it has been presented. - I attached a second video with the overflow tag removed - this issue is present with degree, radian, or gradian measurements used. - This issue is not present in R68 kiosk launched, I'm relatively certain that pre- R69 kiosk launch might have used the OS browser or a different picture entirely. post- R69 its seems to be using the same shell as packaged applications launched as extensions. - thank you
,
Dec 13
I actually resolved the issue with the app not loading with that error (Err_File_notFound) for you. Capitalization sensitivity always gets me on Chrome OS.. Attached.
,
Dec 13
Routing to Platform>Apps as per comment 41.
,
Dec 14
eae: Please take a look at #46 Re #48 I suggest filing a new issue for that. Also, in order to help us debug properly I suggest trying to reproduce the issues in a normal browsing tab. Most of these issues won't be specific to Chrome apps.
,
Dec 14
#51 Re #48 I suggest filing a new issue for that. Could you perhaps help me with this? Comment 48 is the exact issue I have been working in this topic and with support on for the last 3 months. "Rotating a video element causes all other elements not to display" As far as I can tell this is specific to packaged apps, and can't be recreated in browsers. This is why its such a big issue for our company, as most users design the HTML content for our app in a browser. I am unclear how the stacking order relates to this, or how I should present a new issue to gain attention to see this towards some sort of resolution. How packaged apps and kiosk launched packaged apps differ is also something I am unclear on, which seems to be case since this issue appeared with R69 and not before in a kiosk launched app. I appreciate any help here, thank you.
,
Dec 14
> As far as I can tell this is specific to packaged apps, and can't be recreated in browsers.
It's easy to reproduce this in a tab in the browser. Just add html { overlow: hidden; } to style.css.
The rotation issue seems related to the issue in #46. I'll again defer to the style team.
,
Dec 14
*layout team rather
,
Dec 14
I think this is where the disconnect is. I attached two videos here both in firefox and chrome browsers. I see no issue in either. I toggle overflow setting and go as vanilla as possible with the other css, and see no difference. I did this both on chrome OS and windows based machines.
,
Dec 14
Re 53, raymes: Do you have a way to reproduce this in the browser? None of the linked test cases reproduce for me, on any device. If you have a test case that demonstrates the problem could you please attach it and then reassign the issue back to me? Thanks!
,
Dec 16
eae: see the attached zip. When I open index.html in my Chrome the text is hidden and I just see a green background. When I open it in FF the text is visible. Does this repro for you or is there something else going on in my setup? I'm on M71 linux.
,
Dec 16
,
Dec 16
re: #55 you're toggling overflow: hidden on the <body> element. However I'm suggesting that you need to add it to the <html> element in order to repro this in the browser. See the attached zip file above in #57.
,
Dec 17
This is understood now, and is the same bug.
Packaged apps add the overflow:hidden to the parent element by default, it must also apply overflow:hidden to child elements as well. Since toggling overflow does not resolve issue in packaged apps. Adding overflow:visible to the HTML{} does allow toggling overflow hidden in lower elements to resolve in packaged apps though.
I don't require a second issue created if the stack issue is being resolved.
Thanks,
,
Dec 17
Thanks! Appears to be a painting issue with video elements, the wrapper is positioned correctly and the test hit tests right but is painted beneath the video element.
,
Dec 18
When I get a chance I'll bisect, or try to.
,
Dec 18
We are not detecting the overlap when the rotation passes 90deg, and hence the need for a compositing layer due to overlap. Bisecting now.
,
Dec 18
,
Dec 18
,
Dec 18
Not a regression either.
,
Jan 7
chrishtr: could you ptal? Thanks |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Comment 1 by eric.mel...@wandcorp.com
, Sep 2422.9 KB
22.9 KB Download