Issue metadata
Sign in to add a comment
|
DevTools detach/close unconditionally reset BaseBackgroundColorOverride
Reported by
dev.xfo...@gmail.com,
Jan 9 2018
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36 Steps to reproduce the problem: Probably not really a problem for chromium, Chromium Embedded Framework supports transparent background colors. I noticed some issues when closing the DevTools where the background color resets to white. CEF issue for reference: https://bitbucket.org/chromiumembedded/cef/issues/2345/osr-detaching-closing-devtools-resets What is the expected behavior? What went wrong? I noticed that the DevTools detach logic unconditionally calls ClearBaseBackgroundColorOverride. This causes some issues in Chromium Embedded Framework with a transparent background color where it was reset to white on closing the DevTools. I believe that the DevTools shouldn't unconditionally reset the base background color override because it may have been set before. For example in RenderViewImpl::OnSetBackgroundOpaque(bool opaque) it is possible that the BaseBackgroundColorOverride was set to transparent. This then gets reset when the DevTools detach. This was introduced in this change https://codereview.chromium.org/2643723008/ In this change however the reset was to Transparent. In the next change to InspectorEmulationAgent.cpp here https://codereview.chromium.org/2704213002 it was changed to call ClearBaseBackgroundColorOverride instead. I am not that familiar with the Chromium code base and it already took me quite a while to get to all this information. I hope that I am not missing something. So if I am not mistaken the RenderViewImpl sets the BaseBackgroundColorOverride on the WebView which then can get reset by the DevTools. Did this work before? Yes 58.0.3029.145 Chrome version: 63.0.3239.132 Channel: stable OS Version: 10.0 Flash Version:
,
Jan 15 2018
I feel like I may have worded that poorly. I wasn't trying to suggest that chromium should change it's behavior just to 'fix' a bug in CEF. I was only trying to report findings of what I believe could be an issue inside chromium in the way the base background color override is handled, not really right now, but in the future if someone decides to use the base background color override in other places. I hope that makes my intention more clear, as it feels like I was giving the impression that I am reporting a CEF bug here when I saw your response.
,
Feb 18 2018
This is also a problem in electron. That too is not a chromium.org project, but both CEF and electron depend on chromium, and seeing how this bug is present in both projects, it is fair to say that it is a bug in chromium.
,
Feb 19 2018
Another way of dealing with this would be settings the BaseBackgroundColor instead of relying on RenderViewImpl::OnSetBackgroundOpaque(bool opaque), since when the BaseBackgroundColorOverride is reset, it resets to the BaseBackgroundColor value. This fixed stuff for us in electron.
,
Feb 19 2018
Indeed, that's also what I did in CEF to fix it. That said, I still think that the behavior in chromium is 'wrong', I think it's always bad to reset things unconditionally that you (DevTools in this case), haven't changed. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by eostroukhov@chromium.org
, Jan 9 2018