Chrome : websocket connection not closed when browser closed - google-chrome

I am using Netty websockets and everything seems to work fine except this minor issue :
If I close the browser / tab of the js websocket client , the websocket connection is automatcally closed when using Mozilla firefox (currently using firefox 14) but the same thing does not happen in Chrome 20/21.
Anyone seen a similar issue / can anyone tell why is the connection not closed automatically ?

I guess I should have checked this earlier in the chromium bug section but I was not sure if it is a bug.
It has been reported earlier by someone and a chromium bug already exists :
Issue 51687 : WebSocket: Send close with code 1001 on reload / tab close
Update : Someone has submitted a patch to fix this issue, can be seen in the above link.

This may not be right, but I cannot post a comment to your question. Chrome/Chromium does not really close if you have an App running and have selected "Continue running background apps when Chromium is closed" from Settings-->Under the hood.
It may be that it treats the websocket connection as an app. Try looking at your running processes and kill any chrome/chromium process you find.
Again, this is just speculation on my part.

Chrome doesn't close the connection, when a user will close the window or browser.
It will trigger an Error event.
A possible workaround could look like this:
#OnError
public void onErr(Throwable t) {
onClose(this.container.getWsSession(), null);
}
But this will close the connection every time, an Error is triggered. You may wan't to check the throwable, before closing the connection by yourself.
For more discussion, please join this question:
Websocket: Closing browser triggers onError() in chrome but onClose() event in Firefox

Related

IdentityServer4 - redirects in Chrome stopped working

I have an implementation of IdentityServer (v3.1.4 nugets) running in ASP.Net Core 3.1. On my dev machine (windows 10), Chrome will not redirect back to my Angular site after successful authentication, ie:
var result = await _signInManager.PasswordSignInAsync(model.Email, model.Password, model.RememberMe, lockoutOnFailure: false).ConfigureAwait(false);
if (result.Succeeded)
{
_logger.LogInformation("User logged in.");
return RedirectToLocal(returnUrl);
}
...
If just ends up back at the login prompt.
Chrome Incognito also fails.
Clearing Chrome cache didn't help.
Rebooted a few times too.
Using FireFox works fine.
Also works fine in test and prod environments (Ubuntu host).
Also works on another dev's machine.
This has been working fine all year. This started after a windows update last week. There was no code change to this part of the front end app or identity server for months.
returnUrl is like:
/connect/authorize/callback?response_type=id_token%20token&client_id=xxxxx.client.js&state=dXF2ZkFpRVFMTjNOY2JPcGxfVVJ3c1VqbXpleDVvU0xrNGRWZ1I1Uzzzzzz&redirect_uri=http%3A%2F%2Flocalhost%3A4200%2Fauthenticate&scope=profile%20openid%20xxxxx.api.v1%20yyyyy.api.v1&nonce=dXF2ZkFpRVFMTjNOY2JPcGxfVVJ3c1VqbXpleDVvU0xrNGRWZ1I1UEpVQ3NH
I guess this is more of an annoyance than a shop stopper but it's convinced me to use Firefox for my main browser now - final straw for Chrome - it's is the new IE.
Problem resolved. Chrome has been warning me about SameSite cookies for so long I had ignored them. Finally, it got sick of me ignoring it. :)

Permission issue for appium chrome borwser

I am implementing an appium test on remote android driver, with chrome browser for loading urls.
Some of the Urls are pdfs, and chrome asks to store those files. and appears that chrome doesnt have access to filesystem to store those files, which results in a dialog like below.
Please help me pass that dialog without any manual inputs.
Upon clicking continue, it will load actual permissions dialog from Android.
Here is my code initialize appium capabilities
DesiredCapabilities caps = DesiredCapabilities.android();
caps.setCapability("appiumVersion", "1.9.1");
caps.setCapability("deviceName","Samsung Galaxy S9 Plus HD GoogleAPI Emulator");
caps.setCapability("deviceOrientation", "portrait");
caps.setCapability("browserName", "Chrome");
caps.setCapability("platformVersion", "8.1");
caps.setCapability("platformName","Android");
caps.setCapability("autoAcceptAlerts", true);
caps.setCapability("autoGrantPermissions", true);
caps.setCapability("chromedriverArgs", "--allow-file-access-from-files");
caps.setCapability("maxDuration", 10000);
and this is the snippet I use to load a Url
driver.navigate().to("http://kmmc.in/wp-content/uploads/2014/01/lesson2.pdf");
autoGrantPermission also doesnt work in this case because chrome is already installed. Appium team has already rejected this issue -
https://github.com/appium/appium/issues/10008
Please help!
Indeed I had very hard time finding out the solution, but eventually I found a workaround.
The best workaround would have been reinstalling the chrome package. I tried that, but I could not start chrome after reinstalling it, as I had no access to shell, and chromedriver complained. So I left that track.
I tried getting hold of adb command or mobile:changePermissions but for that you need to use server flag --relaxed-security while starting the server, and saucelabs doesnt provide any handy interface to start the server with this flag.
The last resort, I found a solution here - https://stackoverflow.com/a/51241899/4675277 . But just that was not sufficient, because it helped me fix chrome alert, but later on it popped up with another alert with allow and deny, for which another solution in the same question helped me. So this is the code I eventually used -
driver.navigate().to("http://kmmc.in/wp-content/uploads/2014/01/lesson2.pdf");
String webContext = ((AndroidDriver)driver).getContext();
Set<String> contexts = ((AndroidDriver)driver).getContextHandles();
for (String context: contexts){
if (context.contains("NATIVE_APP")){
((AndroidDriver)driver).context(context);
break;
}
}
driver.findElement(By.id("android:id/button1")).click();
contexts = ((AndroidDriver)driver).getContextHandles();
for (String context: contexts){
if (context.contains("NATIVE_APP")){
((AndroidDriver)driver).context(context);
break;
}
}
driver.findElement(By.id("com.android.packageinstaller:id/permission_allow_button")).click();
((AndroidDriver)driver).context(webContext);
This helps allow all permissions required.

Strange Angular PWA Service worker behaviour when deployed

This issue has taken up all my day, and I can't figure out whats going on
I can see that my service worker is registered , however "sometimes" when I click offline in developer tools the ServiceWorker for my domain just disappears!!
But this is the main problem when I reload the app I see the following behaviour.
You can see the ngsw.json is loaded twice and the main.js is loaded 3 times! main.d3ae2084xxxx && main.bbe5073dxxxx && then main.d3ae2084xxxx again!
If I inspect the response of both ngsw.json requests you can see that both show main.d3ae2084xxxx as the correct version of main.js but it still loads main.bbe5073dxxxx...
First ngsw.json request
Second ngsw.json request
Whats even more frustrating is the actual loaded version is the previous main.bbe5073dxxxx...!!!!
If anyone has any ideas how this can be happening please let me know.
Update... So found out about this excellent little endpoint
https://you-app-url/ngsw/state
This will give you lots of debug information about your service worker.
In my case this
Driver state: EXISTING_CLIENTS_ONLY (Degraded due to failed
initialization: Hash mismatch (cacheBustedFetchFromNetwork):
https://dev-xxxx.net/main.eb8468bb3ed28f02d7c2.js: expected
b5601102b721e0cf777691d327dc965d40d1c96e, got
83c18fdb4a5942c964a31c119a57e0b8e16fe46e (after cache busting)
So looks like this is going to be a CDN issue of some sort in my case, will update with an answer when I know for sure.
You've probably resolved this by now, but I had the same issue which turned out to be due to the CDN (Cloudflare in my instance) was optimising the content.
In Cloudflare the key option is 'Auto minify' that needs to be disabled.

Notification.requestPermission() doesn't work on Chrome

I'm having a problem with push notifications on Chrome. On certain pcs in my network, websites normally requesting permissions to post push notifications, don't request them. That functionality works on some browsers in my network, but doesn't on others. Chrome version is 68.0.3440.106 on all the machines.
To investigate the case, I run a simple script in the console, that should trigger the browser request:
Notification.requestPermission().then(function(result) {
if (result === 'denied') {
console.log('denied');
return;
}
if (result === 'default') {
console.log('default');
return;
}
console.log(result);
return;
});
On the machines where push is working as expected, this promise resolves, whereas on the "faulty" ones, it doesn't resolve. I don't have my browser configured to either allow or deny the notifications (I've never clicked the "allow" or "deny" on the request, as it has never appeared). I don't know where to go from here, here's what I've tried so far:
I don't have the browser notification behaviour set to either allow or deny.
Chrome://flags shows "default" for all entries concerning push notifications.
Console doesn't print any errors/warnings
running chrome with --enable-logging --v=1 doesn't show anything suspicious when running the script. Here's an excerpt:
[7772:21772:0828/101500.364:VERBOSE1:thread_state.cc(1024)] [state:00007FFB173B67A0] PostSweep: collection_rate: 0.00067%
[7772:21772:0828/101500.421:VERBOSE1:thread_state.cc(1024)] [state:00007FFB173B67A0] PostSweep: collection_rate: 0%
[7772:21772:0828/101500.422:VERBOSE1:thread_state.cc(1430)] [state:00007FFB173B67A0] CollectGarbage: time: 15ms stack: HeapPointersOnStack marking: AtomicMarking sweeping: EagerSweeping reason: ForcedGC
[7772:21772:0828/101500.427:VERBOSE1:thread_state.cc(1430)] [state:00007FFB173B67A0] CollectGarbage: time: 4.9ms stack: NoHeapPointersOnStack marking: AtomicMarking sweeping: LazySweeping reason: PreciseGC
I'd really appreciate it if someone could tell me what else to check, I'm really lost with this one. Thanks in advance!
Edit: Apparently this is some weird screen offset issue. The request shows just fine, when I have two instances of chrome running. However, when I have the request showing in one window, snapping it back to the other instance makes the request disappear. It reappears after resising the window to anything but fullscreen, or undocking the tab. Has nobody encountered this problem? This occurs among multiple machines in my workplace

Calling Rest service with json return, issue in chrome

I have a Rest service which if I execute it in IE or Firefox it executes fine.
http://MyPC.com/Services/REST.svc/Work/Lists?$format=json
But when I try to execute it in Chrome I just get this error.
http://MyPC.com/Services/REST.svc/Work/Lists?$format=json:1 GET http://MyPC.com/Services/REST.svc/Work/Lists?$format=json net::ERR_CONNECTION_RESET
Has anyone experienced this before and find a way to resolve it.
I've played around with the bindings in the config with no success
Just a note, I tried another Rest Service which I wasn't hosting and it worked in both IE and Chrome.
So it doesn't look like the issue is with Chrome.
I just want to add I didn't write any of these services, I'm still figuring it all out
Seems it sending the windows credentials through in binding did the trick, Chrome for some reason throws a connection issue when it didn't have the credentials for the service where as IE and Firefox seem to sk for the credentials when its required