Issue metadata
Sign in to add a comment
|
gCrWeb throws DataCloneError in iOS - no way to figure out how/why
Reported by
erica.gu...@updater.com,
Jan 2
|
||||||||||||||||||||||||
Issue descriptionSteps to reproduce the problem: 1. using our application with shadow dom, custom components 2. take normal actions in our application 3. see DataCloneError - The Object Cannot Be Cloned by try/catching around problem errors and seeing in the stack trace an issue in PostMessage API What is the expected behavior? Nothing should fail. The odd thing is the issue starts with radio buttons or checkboxes (our custom implementation which does things like set tabindexes and dispatches change events). The components also need to be in shadowDom (forcing shadyDom polyfill seems to fix the issue). The issue then actually breaks our application when we attempt to navigate the user via history.pushState. history.pushState throws this error only when having interacted with our radio / checkbox. Calling __gCrWeb.messages.getMessageQueue() before calling history.pushState prevents the dataCloneError from being thrown at this point. What went wrong? postMessage is called by invokeOnHost which is called by _gCrWeb as it wraps native functions like history.pushState on ios chrome. I was able to get the error to stop by doing _gCrWeb.messages.getMessageQueue() which also seems to "reset" the queue from the logging i did against the minified script. This is not a suitable long term fix and theres no telling if calling this function has other inunintended consequence Did this work before? N/A Does this work in other browsers? Yes Chrome version: 70.0.3538.102 Channel: n/a OS Version: OS X 10.13.5 Flash Version: I am perfectly welling to debug the __gCrWeb script and provide more information. I am also going to be working on reducing our application down to the smallest reproducer. Please let me know if there is a way i can get the __gCrWeb script in my regular chrome so i can use debuging tools and breakpoints and track down the exact cause of the issue.
,
Jan 3
After further debugging, I believe the actual root cause of the error in this case is the `log` rather than `promiseJobReaction`. I worked on better logging around this stack trace and now it appears as so (see screenshot). `log` is found to be equal to another thing i have not seen before - `function () { f("log", arguments)`, but i recognize `f` from the stack trace of the original `history.pushState` issue. Conclusion: The error bubbled up in one of two ways, either via `history.pushState` or via `console.log`, each which will call into `invokeOnHost` which eventually dies. I believe both of these functions are failing due to being modified by the gCrWeb user script.
My next course of action will be to finalize the reproducer I created now that I've identified "Log" is the issue. It will still take some time as I want to try as best possible to minimize the amount of "code noise" needed to create the issue. Working without dev tools, however, makes it more difficult.
Appreciate anyone's help on this since I've been working on it since before holiday season.
,
Jan 3
Here's a screenshot for reference of `history.pushState` code demonstrating the interference by gCrWeb. Considering `invokeOnHost` appears in the above stack trace as well and appears to be implemented by `gCrWeb` script, I think that `console.log` is also being wrapped by gCrWeb, even though my logging in the above screenshot only has `f` in there.
,
Jan 3
i now have a reproducer for this issue and will open a new ticket for clarity
,
Jan 4
I apologize for not understanding this wizard or forum, because i was trying to re-make this issue but Specify i had a test case or reproducer but was unable to do so. Regardless, the new issue is here -> https://bugs.chromium.org/p/chromium/issues/detail?id=918988 I will keep on top of checking both for responses but feel free to close one or the other.
,
Jan 4
Eugene: other part of issue 918988 , feel free merge them if you think it is relevant.
,
Jan 4
,
Jan 8
Thank you for all the details. I apologize for the delay, as I was OOO until yesterday. For reference, the scripts you are seeing do in fact override console.log. (And we've been doing this for a very long time.) However, I recently changed this to forward the log message to the original log function. (Previously, we were overriding and intercepting, but that broke normal console logging.) The overriding of the console functions are here: https://cs.chromium.org/chromium/src/ios/chrome/browser/web/resources/console.js?l=34 and other scripts are here: (i.e. functions is __gCrWeb.message are defined in message.js) https://cs.chromium.org/chromium/src/ios/web/web_state/js/resources/ I'll take a look at the other bug and see if I can pinpoint what is happening here.
,
Jan 8
Merging this issue into the one with a reproducing case. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by erica.gu...@updater.com
, Jan 256.4 KB
56.4 KB View Download