Chrome (open) Shadow DOM Events Not Reaching Host - google-chrome

I'm running Chrome 56.0.x (corporate mandate), along with Polymer 2. My sample component isn't doing anything fancy; just raising a CustomEvent after making a simple AJAX call. I'm setting "bubbles":true and "composed":true, and I can validate that the event is dispatched and that my host is listening for the event properly.
sample-component.html
raiseDataRetrievedEvent() {
this.dispatchEvent(
new CustomEvent('sample-component-data-retrieved', {
bubbles: true,
composed: true,
detail: { data: "loading complete" }
}));
}
However, the events never make it out of the Shadow DOM to my host page listeners.
index.html
// Listen to Custom event from Sample Component
document.querySelector('sample-component').addEventListener('sample-component-data-retrieved', function (e) {
alert(e.detail);
console.log(e.detail);
});
Interestingly enough, when I have a user initiated event (e.g. click) trigger this CustomEvent, it happily makes its way through the Shadow DOM to my listener. It's just the events that are programmatically created that are getting stuck.
UPDATE 1
This issue only seems to manifest itself when I'm serving my site locally (e.g. http://localhost, http://127.0.0.1, http://COMPUTERNAME). When I publish the site to another host, all the events seem to propagate as expected. Feels to me more like a Chrome issue at this point...
UPDATE 2
I put my code out on github here: https://github.com/davidfilkins/polymer-test.
I did some more testing and the results keep getting weirder... when I'm developing / testing in Chrome, I almost always have Dev Tools open. I noticed strangely enough that when my tools are open, that the event isn't captured by the host page (index.html)... but this seems to only happen locally. When I close tools and load the page locally, the events bubble properly... But this is only for the dispatched events that aren’t tied to an explicit user action; those all seem to work regardless of the tools being open or not.
When I access the simple Azure app that I created - http://samplepolymertwo.azurewebsites.net/index.html - all events are bubbled / captured regardless of whether the tools are open.
No clue if this is fixed in more current versions of Chrome or not.

The culprit was all timing...
In Chrome, with Dev Tools open, running on localhost, the event was dispatched from the component before the event listener was wired up on the host page.
Event Timing
I suppose the ideal scenario would be for the web component to wait until the event listener on the host had been wired up before broadcasting the event.

Related

See what file/function deals with a WebSocket?

Is there a way to, possibly using the Chrome DevTools, see in what javascript file or function a WebSocket is handled with?
For instance, I am able to see the frames of the data in the Frames tab, but I am not able to find where they are handled. Is this even possible using only Chrome's DevTools?
I think doing a full-text search of the page source for "onmessage" is the easiest way of doing this.
Other than that, a more accurate method is to overwrite the native WebSocket object and putting in a debugger statement:
var nativeWebSocket = window.WebSocket
window.WebSocket = function(){
debugger
}
Paste this in the console before the WebSocket is created. You can use "Script First Statement" in Event Listener Breakpoints to pause when the page starts loading.
Chrome will pause when the WebSocket object is created, and you can go up the call stack to find the source code that's responsible.
This may be very different from where the onmessage handler is defined. However, you can then put a manual breakpoint on the line that contains new WebSocket, reload the page, and put this code in the console when the breakpoint is hit:
Object.defineProperty(e, "onmessage", {
set: function(){
debugger
}
})
Now the debugger will pause when the onmessage property is set on that WebSocket object.

Wait for App to idle after Interruption

I have a ViewController that will request access to location services on init via
if ([CLLocationManager authorizationStatus] == kCLAuthorizationStatusNotDetermined)
{
[_locationManager requestWhenInUseAuthorization];
}
This triggers the "Allow app to access your location while you use the app?"-alert.
I use [self addUIInterruptionMonitorWithDescription:handler:] to react to this. I am encountering the following problem: after dismissing the request-dialog, the ui-test does not continue. The alert is dismissed, but Xcode waits for the app to become idle, but it looks like the app is idle:
t = 67.35s Wait for app to idle
The test fails, because the app is stuck here. If i tap into the simulator, Xcode logs.
t = 72.27s Synthesize event
and continues the test.
Is there a reason, why Xcode tries to wait for the app? A workaround seems to be to tell Xcode that the UI changed or an event happened. Is there a way to trigger this?
After presenting the alert you must interact with the interface. This is a known bug with Xcode 7.2. Simply tapping the app works just fine, but is required.
addUIInterruptionMonitorWithDescription("Location Dialog") { (alert) -> Bool in
alert.buttons["Allow"].tap()
return true
}
app.buttons["Find Games Nearby?"].tap()
app.tap() // need to interact with the app for the handler to fire
XCTAssert(app.staticTexts["Authorized"].exists)
See my blog post for more information.

chrome.runtime.connect from Content Script and DevTools Page JS failing to connect

I have reviewed this question/answer as well:
Communicating between Chrome DevTools and content script in extension
It looks like they are doing something slightly different than I am trying to do, so I don't know how much it applies. Maybe I absolutely need a background.js file?
I have also reviewed this question:
extension using background, content and devtools together
Here it looks like they are not using long-lived connections as documented here (which is what I need):
https://developer.chrome.com/extensions/messaging#connect
Anyway, previous question aside here is my problem:
I have tried this a few ways over the span of a few hours so I am pretty convinced I am just missing something here to make this work.
The crux of my issue is that:
chrome.runtime.onConnect.addListener(function(){...})
the listener here will never fire.
Here's my setup:
My extension uses a Content Script and a DevTools page. From both locations, the Content Script and DevTools page, I have tried to enabling messaging though chrome.runtime. My boilerplate initialization looks like this for starting the connection:
console.log('initializing connection');
var port = chrome.runtime.connect({name: 'My Extension'});
console.log('port', port.name);
and this for waiting for onConnect:
chrome.runtime.onConnect.addListener(function(port){
console.log('got connection!!!!!!');
});
My onConnect handler will never be invoked. I have tried placing the connection code (chrome.runtime.connect({...})) in the Content Script and in the DevTools page JS while placing the handler initialization the opposite location to no avail.
In other words, if I place the connection code in the Content Script, I will place the handler initialization into the DevTools page JS. If I place the connection code into the DevTools page JS I will place the handler initialization into the Content Script.
In both cases, I receive no runtime errors, however, I also never see the console.log('got connection!!!!!!'); get called. Yes, I am looking at the DevTools page console when I have the handler initialization located in the DevTools page JS.
I simply must just be misunderstanding something or missing something in the docs. Can anyone point me in the right direction re: having DevTools Page JS communicate with a Content Script?
As per Xan comment, communication between devtools extension and content scripts should be done through the use of a background script. The process is basically:
(devtools script) - create the connection ( and sends or listens to messages through the connection port opened)
(background script) - listen for the connection to be created, receiving the port and using it to listen or broadcast messages
This is useful if you want to keep a long lived connection, so basically you will need a couple of messages to be passed back and forward for a single process. If you want simple messages to be passed from time to time, but don't need multiple messages being passed back and forth then you might implement a more simple communication:
(devtools script) - sends a message using the chrome.runtime.sendMessage
(background script) - listens for messages send by any extension associated with it using the chrome.runtime.onMessage.addListener()

How to get appWindow from Chrome.app.window.create

I am trying to write a chrome.app that is able to open and close chrome.app windows on both displays of a system that is configured with two monitors. When launched, the chrome application establishes a socket connection with a native application running on the same computer, I also open a hidden window via chrome.app.window.create to keep the chrome application up and running. The native application then reads a configuration file and then sends a series of ‘openBrowser’ commands to the chrome application via the socket.
When the chrome application receives an ‘openBrowser’ command, the chrome application makes a call to the chrome API method chrome.app.window.create, passing the create parameters AND a callback function. A code snippet is below:
NPMBrowserManager.prototype.openBrowser = function (browserId,htmlFile,browserBounds,hidden,grabFocus)
{
var browserManager = this;
var createParameters = {};
createParameters.bounds = browserBounds;
createParameters.hidden = hidden;
chrome.app.window.create(htmlFile,createParameters,function(appWindow)
{
// Check to see if I got a non-undefined appWindow.
if(appWindow !== null)
{
browserManager.browsers.push({"browserId":browserId,"window":appWindow});
console.info("NPMBrowserManager.openBrowser: Added browser, id =" + browserId + ", count =" + browserManager.browsers.length);
}
});
}
Unfortunately, the ‘appWindow’, parameter passed in the create callback is always undefined. I suspect it has something to do with the fact that the method openBrowser is itself being called by another method that processes commands received from the native application. However, the window opens exactly here and when I want to to, I just can’t seem to cache away any information about the new window that can be used later to close or move the window.
I want to be able to cache away the appWindow so that I can close or modify the created window later on in the workflow.
As a side note, I’ve noticed that appWindow is NOT undefined if I call the openBrowser method from within the callback that is associated with the chrome.app.runtime.onLaunched event. I suspect it has something to do with the current script context. I was not able to find any chrome.app documentation that goes into any detail about the chrome app architecture.
I would GREATLY appreciate it if anyone out there can explain to me how I can get the appWindow of the window that is created in the chrome.app.window.create method. By the way, I have also tried calling chrome.app.window.current to no avail… Very frustrating!!!
I’d also be interested in any documentation that might exist. I am aware of developer.chrome.com, but could not find much documentation other than reference documentation.
Thanks for the help!
Jim

Saving flash game state to server after window.onbeforeunload when swf is cross-domain

My Facebook app is a flash game. I want the game swf to save its latest state to the server when the window unloads. Since I embed the swf with swfobject, I use its embed handler to add a onbeforeunload listener to window:
function embedHandler(event)
{
shell=event.ref;
window.onbeforeunload=function(event)
{
shell.message("save", null);
//delay the unloading a bit so flash has time to contact server
var now = new Date().getTime();
var later=now+50;
while (now < later)
{
now = new Date().getTime();
}
}
}
Here's the problem. This works every time when the swf is loaded directly from the app (a rails app). It never works when the swf is loaded from Amazon.
All the cross-domain issues are worked out between the swf and the app--the rails app accepts calls from Amazon swf, and the Amazon swf loads data from the rails app.
ExternalInterface also works for both outgoing and ingoing calls. But I suspect this is nonetheless a browser security issue, since the inward-going ExternalInterface call only fails when:
it is called from inside the window.onbeforeunload handler
the swf originates from Amazon.
What is the problem? How does one unobtrusively save game state when the game is from a CDN and the save is triggered by onbeforeunload in Javascript? Or is there a better way to accomplish this same thing?
Testing in Firefox.
ExternalInterface also works for both outgoing and ingoing calls. But
I suspect this is nonetheless a browser security issue, since the
inward-going ExternalInterface call only fails when:
it is called from inside the window.onbeforeunload handler
the swf originates from Amazon.
From the sounds of it you worked out all the security issues.
It is more likely a lack of understanding on your part on what is going on behind the scene when onbeforeunload is triggered.
This is a function that will not wait for your "game.swf" to finish the call back via ExternalInterface.This is why you added a stalling mechanism to delay that process. However, I will assume here that this works from the rails app because that is a local server and you are not subject to the lag monster.
Now you might be thinking well I put in a delay it should work. Well that delay is on 50 milliseconds. Try increasing to to 5000(5 seconds) and you should see it start to work on the cdn.
The saving of data should be controlled via the flash app and not triggered by an outside source.
In the game itself you should have milestones that should trigger a save event.
In closing I do want to add that is by far the worst method you could use to save information up to a server. onbeforeunload is unreliable and is subject to cross browser issues let alone putting a lag loop in the JavaScript is just a bad idea and in the end just annoy your users to the point that they won't return.