Closed hugomano closed 5 years ago
there is an error
withpostMessage
that doesn't work because theopener
is undefined
Any idea of the root cause of this? Worth adding it for reference.
The whole window-setup file is here to polyfill this Electron issue: electron/electron#9961
~What is the issue and how is the polyfill solving it? electron/electron#9961 seems to be the exact bug the original implementation was trying to solve.~
OK I understood. I thught there was a diff with the original implementation.
Should be backported in Station and Electron (we spent a lot of time to find the root source of the bug).
For Electron, worth at least opening an issue.
For Station, what is the plan to not forget about it?
The window.open is triggered from a webFrame. The opened window use postMessage that forwards to the content-script correctly. The propagation stops to work at the iframe window context where lives a proxy between Mixmax extension, and Mixmax web app doesn't catch the onMessageEvent. We tried to override the iframe context with webFrame.getFrameForSelector but it is not possible right now since there is no preload for
This part is still not clear to me:
webFrame
. T'es sur c'est pas une iframe
? c'est ce qui est marqué dans un comment du code.at the iframe window context
ca veut dire quoi? Which iframe actually?Maybe setup the context and the normal behavior before explaining what is wrong:
- there is a Mixmax iframe loaded in the Gmail webview
- the iframe opens a popup via
window.open
- the popup uses
opener.sendMessage
that, in theory, should dispatch aMessageEvent
on Gmail's webview'swindow
object.- However...
Can we change the base to master now?
After merged master on this branch, it does not seem to work for me:
Works for me
For Electron, worth at least opening an issue.
Yes!
For Station, what is the plan to not forget about it?
Add to our Jira backlog
Ok, let me explain you step by step the post message pipeline triggered by the google OAuth callback.
chrome-extension://ocpljaamllnldhepankaeljmeeeghnid/src/iframeProxy/proxy.html?proxy=https%3A%2F%2Fapp.mixmax.com%2Fextension-onboarding%3Fuser%3Dtestapp%2540getstation.com%26client%3Dgmail
open a window from the webview contextwindow.opener
=> window opener context is the webview top context bridged via window-setup
window-setup
logicWe tried to apply the same logic from the window-setup
for top context and content scripts at the iframe context level but it doesn't work. We have added a DOM mutation observer to detect these added iframes.
Then, we execute javascript in their contexts to override the dispatch event related to the postMessage from the ELECTRON_GUEST_WINDOW_POSTMESSAGE
. The result is that we are not executed in the iframe preload since the concept does not exist at this time and dispatch an event that is not from the same origin trigger a CORS error.
I hope I'm clearer than before
~~I've sliced off the codebase to focus us on the root problem.
It's not about window.open
directly but only about the fact that a native window is an orphan: window.opener
is undefined. We polyfill the property by handling guest view manager events in our preload that is correctly set up in the newly opened native window.~~
See the PR description
Event dispatch step by step:
postMessage
eventsonMessage
listeners in the iFrameWe tried to retrieve the iFrame window context via webFrame.getFrameForSelector
, it worked.
The dispatch failed because the origin was not the same between mail.google.com
and chrome-extension://...
.
Next steps
Event
Published as PR here: https://github.com/electron/electron/pull/16406
What is this PR
This PR is intended to fix a problem with message forward between windows context. With Mixmax we can start the extension correctly but at the onboarding, when the google modal triggers the extension callback, there is an error with
postMessage
that doesn't work because the opener is undefined (ref: https://github.com/electron/electron/issues/16200).Important: this
window-setup
is compatible with our current one wich is hereHow does it work: how to fix the bug, and how it was implemented
This bunch of code polyfill the
window.opener
in the opened window since there is an issue on the electron, change the dispatched event type and add a Mixmax specific code block.We use
MessageEvent
instead ofEvent
The small diff is that instead of using
Event
for forwardingpostMessage
we useMessageEvent
is now
We do this because jQuery sucks in the event detection on webapp and extension side.
Should be backported in Station and Electron (we spent a lot of time to find the root source of the bug)not a prerequisite for now.We add a small chunk for Mixmax
We added the code block because the event propagation is blocked at the iframe level (iframe CORS origin blocked in Electron).
It's a workaround for this Electron issue: https://github.com/electron/electron/issues/9581Thewindow.open
that opens the authentication popup is being called from aniframe
, and given preload are not running iniframe
, the override ofwindow.open
is not present.Thewindow.open
is triggered from awebFrame
. The opened window usepostMessage
that forwards to the content-script correctly. The propagation stops to work at the iframe window context where lives a proxy between Mixmax extension, and Mixmax web app doesn't catch theonMessageEvent
. We tried to override the iframe context withwebFrame.getFrameForSelector
but it is not possible right now since there is no preload for<iframe>
.Test instructions
using Mixmax extension
Before this PR
With this PR