Closed ephung01 closed 3 years ago
For the cases where we want to have a timeout we compose waitable with WaitableTimeout
, this should be enough for current use cases and leave enough flexibility in how runUntil works. If understand correctly, you are trying to close the browser and then this code hangs in an infinite loop. This sounds like a bug as when browser closes the connection should close as well and next call to connection.processOneMessage()
is expected to throw. Can you share code snippet with the infinite loop problem?
The browser did close, but the process is hanging. It's very simple code open url and close browser. I've experienced this only at work environment.
It may be that the browser process didn't exit actually, can you check that the browser process actually exits?
The browser did close, but the process is hanging.
Do you mean Playwright process? Are you calling Playwright.close()
or just Browser.close()
? Seeing your code snippet would be helpful.
import com.microsoft.playwright.*; import com.microsoft.playwright.BrowserType.LaunchOptions; import static com.microsoft.playwright.options.WaitUntilState.DOMCONTENTLOADED;
import java.nio.file.Paths;
public class Test { static Playwright playWright = null; static Browser browser = null; static BrowserContext context = null; static Page page = null;
public static void main(String args[]) throws Exception {
try {
playWright = Playwright.create();
BrowserType browserType = playWright.chromium();
LaunchOptions options = new LaunchOptions();
options.setExecutablePath(Paths.get("C:\\Program Files (x86)\\Microsoft\\Edge\\Application\\msedge.exe"));
options.setHeadless(false);
options.setChromiumSandbox(true);
browser = browserType.launch(options);
context = browser.newContext(
new Browser.NewContextOptions()
.setViewportSize(800, 600)
);
page = context.newPage();
String url = "http://www.microsoft.com";
page.navigate(url, new Page.NavigateOptions().setWaitUntil(DOMCONTENTLOADED));
} catch (Exception ex) {
ex.printStackTrace();
} finally {
// tear down
if (page != null) {
page.close();
page = null;
}
if (browser != null) {
browser.close();
browser = null;
}
if (context != null) {
context.close();
context = null;
}
if (playWright != null) {
playWright.close();
playWright = null;
}
}
}
}
Visually the browser is closed, but in Task Manager, there are a few processes are still running (some MSEdge closed when close page)
Look like this is the process suppose to be terminated, but didn't. I manually kill it; the debug code completes gracefully.
Oh, you are running against MS Edge, there has been some fixes related to browser closure in chromium quite recently (this one in particular) and they might not have made it to Edge yet. What version of MS Edge is this?
Also, does it close browser fine with bundled Chromium?
Microsoft Edge version 86.0.622.56. I've the same version at home laptop and it's working fine. In company, users have limited access and will not able to upgrade any browsers (blocked) until approval by security team (chromium is not allow). May be I will wait until new version get approval and test it again.
when I run chromium it will be blocked because it's unauthorized software - base on company policy
Looks like 86.0.622.56 was released in October 2020 so it doesn't include aforementioned patch (and it will likely take a while until you get upgraded to a version which includes it). I wonder though what's different between your laptop and the corp machine that makes it fail on the latter.
Does your corp browser run any extensions that you don't have on your personal device?
There are some default company extension for business and security (cannot add the extension to browser)
Could that be the "Symantec Extension" blocks the process terminate command (playwright.cmd)? We also use Selenium here and browser process termination is not an issue.
Could that be the "Symantec Extension" blocks the process terminate command (playwright.cmd)?
I would say "no" because if the browser process doesn't exit properly within 30 seconds Playwright will kill the process, see this code. You are saying the process keeps running even after 30 seconds since Browser.close()
was sent, right?
Can you enable some logging to see what's going on and upload the logs here:
DEBUG=pw:browser
in the environment (I believe it is something like set DEBUG=pw:browser
on Windows), it should enable launcher logging and also printing of whatever error messages are dumped by Chrome.options.setArgs(Arrays.asList("--enable-logging=stderr", "--v=1"));
Hopefully this will give us some clue about why it's not exiting properly.
"C:\Program Files\Java\jdk1.8.0_121\bin\java.exe" -javaagent:C:\ideaIC-2020.2.1\lib\idea_rt.jar=58509:C:\ideaIC-2020.2.1\bin -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\jdk1.8.0_121\jre\lib\charsets.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\deploy.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\ext\access-bridge-64.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\ext\cldrdata.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\ext\dnsns.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\ext\jaccess.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\ext\jfxrt.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\ext\localedata.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\ext\nashorn.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\ext\sunec.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\ext\sunjce_provider.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\ext\sunmscapi.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\ext\sunpkcs11.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\ext\zipfs.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\javaws.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\jce.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\jfr.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\jfxswt.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\jsse.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\management-agent.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\plugin.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\resources.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\rt.jar;C:\Users\ephung\Development\TestPlayWright\out\production\classes;C:\Users\ephung.gradle\caches\modules-2\files-2.1\com.microsoft.playwright\playwright\1.9.1-alpha-0\dbb6f4a7686b61da408c92fa926c22aae333562c\playwright-1.9.1-alpha-0.jar;C:\Users\ephung.gradle\caches\modules-2\files-2.1\com.microsoft.playwright\driver-bundle\1.9.1-alpha-0\dd9ed2801d0205ed8d97f4c6bdf2a048fde1b922\driver-bundle-1.9.1-alpha-0.jar;C:\Users\ephung.gradle\caches\modules-2\files-2.1\com.microsoft.playwright\driver\1.9.1-alpha-0\943047a4ad4d98143812ca0300fc8bd940a3f22e\driver-1.9.1-alpha-0.jar;C:\Users\ephung.gradle\caches\modules-2\files-2.1\com.google.code.gson\gson\2.8.6\9180733b7df8542621dc12e21e87557e8c99b8cb\gson-2.8.6.jar;C:\Users\ephung.gradle\caches\modules-2\files-2.1\org.java-websocket\Java-WebSocket\1.5.1\382b302303c830a7edb20c9ed61c4ac2cdf7a7a4\Java-WebSocket-1.5.1.jar;C:\Users\ephung.gradle\caches\modules-2\files-2.1\org.slf4j\slf4j-api\1.7.25\da76ca59f6a57ee3102f8f9bd9cee742973efa8a\slf4j-api-1.7.25.jar" Test
2021-03-24T21:31:27.577Z pw:browser
if I have DEBUG=pw.browser only
"C:\Program Files\Java\jdk1.8.0_121\bin\java.exe" -javaagent:C:\ideaIC-2020.2.1\lib\idea_rt.jar=58600:C:\ideaIC-2020.2.1\bin -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\jdk1.8.0_121\jre\lib\charsets.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\deploy.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\ext\access-bridge-64.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\ext\cldrdata.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\ext\dnsns.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\ext\jaccess.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\ext\jfxrt.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\ext\localedata.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\ext\nashorn.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\ext\sunec.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\ext\sunjce_provider.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\ext\sunmscapi.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\ext\sunpkcs11.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\ext\zipfs.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\javaws.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\jce.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\jfr.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\jfxswt.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\jsse.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\management-agent.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\plugin.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\resources.jar;C:\Program Files\Java\jdk1.8.0_121\jre\lib\rt.jar;C:\Users\ephung\Development\TestPlayWright\out\production\classes;C:\Users\ephung.gradle\caches\modules-2\files-2.1\com.microsoft.playwright\playwright\1.9.1-alpha-0\dbb6f4a7686b61da408c92fa926c22aae333562c\playwright-1.9.1-alpha-0.jar;C:\Users\ephung.gradle\caches\modules-2\files-2.1\com.microsoft.playwright\driver-bundle\1.9.1-alpha-0\dd9ed2801d0205ed8d97f4c6bdf2a048fde1b922\driver-bundle-1.9.1-alpha-0.jar;C:\Users\ephung.gradle\caches\modules-2\files-2.1\com.microsoft.playwright\driver\1.9.1-alpha-0\943047a4ad4d98143812ca0300fc8bd940a3f22e\driver-1.9.1-alpha-0.jar;C:\Users\ephung.gradle\caches\modules-2\files-2.1\com.google.code.gson\gson\2.8.6\9180733b7df8542621dc12e21e87557e8c99b8cb\gson-2.8.6.jar;C:\Users\ephung.gradle\caches\modules-2\files-2.1\org.java-websocket\Java-WebSocket\1.5.1\382b302303c830a7edb20c9ed61c4ac2cdf7a7a4\Java-WebSocket-1.5.1.jar;C:\Users\ephung.gradle\caches\modules-2\files-2.1\org.slf4j\slf4j-api\1.7.25\da76ca59f6a57ee3102f8f9bd9cee742973efa8a\slf4j-api-1.7.25.jar" Test
2021-03-24T21:35:56.127Z pw:browser
The process would stuck forever(I left it overnight and still running next day) unless I manually kill it.
Thanks. Do you know when will this get push to maven central? Current version 1.10.0 is not included this change.
Publishing it to 1.11.0-SNAPSHOT, should be available there in a few minutes.
It's still not working with Browser.close(). But if I removed the Browser.close(), playwright is terminated after 30 seconds timeout (which is work - I can live with 30 sec slower). Previously, playwright cannot be terminate and got stuck even after remove Browser.close(). I've tested with Chrome Version 88.0.4324.150 also (latest my company allow) and experienced the same issue.
[Question] With 30 secs timeout, all scripts are now take 30 seconds longer. Is there a way to force kill playwright (without waiting?) - like forceClose()?
NOTE: the error seems to relate to chromium core (C++). I found on internet it also happens with Selenium. I've tried to put chrome options --enable-logging and --no-sandbox, but did not resolve the issue. ERROR:device_event_log_impl.cc(211)] [11:58:41.262] Bluetooth: bluetooth_adapter_winrt.cc:1072 Getting Default Adapter failed.
screenshot 30 seconds timeout after comment out Browser.close():
It's still not working with Browser.close(). But if I removed the Browser.close(), playwright is terminated after 30 seconds timeout (which is work - I can live with 30 sec slower). Previously, playwright cannot be terminate and got stuck even after remove Browser.close(). I've tested with Chrome Version 88.0.4324.150 also (latest my company allow) and experienced the same issue.
Oh, interesting. So playwright driver process (should be something like node.exe package\lib\cli\cli.js
on Windows) must be also hanging, can you check that in task manager? This means that our code that kills browser process on Windows doesn't work in your case.
Can you try running taskkill /pid <browser process id> /T /F
in terminal manually and see what it returns for the hanging process?
[Question] With 30 secs timeout, all scripts are now take 30 seconds longer.
Not a solution to this particular bug but in general we assume that you will create a new context for next test and reuse the same browser instance. The contexts are very cheap to create/destroy compared to launching new process, yet they provide nice isolation between tests. Is there a particular reason you have to restart the browser between tests?
Is there a way to force kill playwright (without waiting?) - like forceClose()?
This is one of the options we discussed (the other was to allow configuring timeout in close()
), the main issue is that on linux (probably on windows too) this would create core dumps on every abnormal process exit which we'd like to avoid. So we are hesitant at the moment.
NOTE: the error seems to relate to chromium core (C++). I found on internet it also happens with Selenium. I've tried to put chrome options --enable-logging and --no-sandbox, but did not resolve the issue. ERROR:device_event_log_impl.cc(211)] [11:58:41.262] Bluetooth: bluetooth_adapter_winrt.cc:1072 Getting Default Adapter failed.
This seems like a benign error to me which should not prevent the browser from exiting. Are there any evidences from others showing their browsers hang because of the same problem? Can you share a link?
It's still not working with Browser.close(). But if I removed the Browser.close(), playwright is terminated after 30 seconds timeout (which is work - I can live with 30 sec slower). Previously, playwright cannot be terminate and got stuck even after remove Browser.close(). I've tested with Chrome Version 88.0.4324.150 also (latest my company allow) and experienced the same issue.
Oh, interesting. So playwright driver process (should be something like
node.exe package\lib\cli\cli.js
on Windows) must be also hanging, can you check that in task manager? This means that our code that kills browser process on Windows doesn't work in your case.Can you try running
taskkill /pid <browser process id> /T /F
in terminal manually and see what it returns for the hanging process?[Question] With 30 secs timeout, all scripts are now take 30 seconds longer.
Not a solution to this particular bug but in general we assume that you will create a new context for next test and reuse the same browser instance. The contexts are very cheap to create/destroy compared to launching new process, yet they provide nice isolation between tests. Is there a particular reason you have to restart the browser between tests?
Is there a way to force kill playwright (without waiting?) - like forceClose()?
This is one of the options we discussed (the other was to allow configuring timeout in
close()
), the main issue is that on linux (probably on windows too) this would create core dumps on every abnormal process exit which we'd like to avoid. So we are hesitant at the moment.NOTE: the error seems to relate to chromium core (C++). I found on internet it also happens with Selenium. I've tried to put chrome options --enable-logging and --no-sandbox, but did not resolve the issue. ERROR:device_event_log_impl.cc(211)] [11:58:41.262] Bluetooth: bluetooth_adapter_winrt.cc:1072 Getting Default Adapter failed.
This seems like a benign error to me which should not prevent the browser from exiting. Are there any evidences from others showing their browsers hang because of the same problem? Can you share a link?
It's still not working with Browser.close(). But if I removed the Browser.close(), playwright is terminated after 30 seconds timeout (which is work - I can live with 30 sec slower). Previously, playwright cannot be terminate and got stuck even after remove Browser.close(). I've tested with Chrome Version 88.0.4324.150 also (latest my company allow) and experienced the same issue.
Oh, interesting. So playwright driver process (should be something like
node.exe package\lib\cli\cli.js
on Windows) must be also hanging, can you check that in task manager? This means that our code that kills browser process on Windows doesn't work in your case. Could that be because of user's ACL (Access Control List) is lack of authorization?Can you try running
taskkill /pid <browser process id> /T /F
in terminal manually and see what it returns for the hanging process?[Question] With 30 secs timeout, all scripts are now take 30 seconds longer.
Not a solution to this particular bug but in general we assume that you will create a new context for next test and reuse the same browser instance. The contexts are very cheap to create/destroy compared to launching new process, yet they provide nice isolation between tests. Is there a particular reason you have to restart the browser between tests?
Is there a way to force kill playwright (without waiting?) - like forceClose()?
This is one of the options we discussed (the other was to allow configuring timeout in
close()
), the main issue is that on linux (probably on windows too) this would create core dumps on every abnormal process exit which we'd like to avoid. So we are hesitant at the moment.NOTE: the error seems to relate to chromium core (C++). I found on internet it also happens with Selenium. I've tried to put chrome options --enable-logging and --no-sandbox, but did not resolve the issue. ERROR:device_event_log_impl.cc(211)] [11:58:41.262] Bluetooth: bluetooth_adapter_winrt.cc:1072 Getting Default Adapter failed.
This seems like a benign error to me which should not prevent the browser from exiting. Are there any evidences from others showing their browsers hang because of the same problem? Can you share a link?
I cannot delete the registry as instructed in the article. http://blogs.stevelongchen.com/2020/05/15/selenium-chrome-driver-resolve-error-messages-regarding-registry-keys-and-experimental-options/
Thanks for checking this! Do I understand correctly that the same
taskkill
command works perfectly fine when you run it manually in command line but fails when we do it from nodejs in response to Browser.close? Do you see line like[pid=12345] <kill>
after you startedBrowser.close()
and it was hanging for 30 seconds? Meanwhile let me add some more logging to that code.
That is correct. When manually do taskkill in command prompt, it terminates the process. When I run using playwright-java to call browser.close(), it hanged - it hang indefinitely (NO timeout). Timeout happens when I don't call browser.close() (comment out) and just call playwright.close() - see image posted with circle red on comment out browser.close().
That is correct. When manually do taskkill in command prompt, it terminates the process. When I run using playwright-java to call browser.close(), it hanged - it hang indefinitely (NO timeout). Timeout happens when I don't call browser.close() (comment out) and just call playwright.close() - see image posted with circle red on comment out browser.close().
I see, thanks for confirming. I'd like you to run Browser.close with the logging added (once I roll it to java).
Reading the stackoverflow thread you referred to and this comment in particular I suspect that it might be a problem with privileges. Could it be that you run your tests as a normal(unprivileged) user but executed taskkill
in command line window which was 'Run as Administrator' ? It might be that if you run your test from terminal started as Administrator the problem will vanish.
Reading the stackoverflow thread you referred to and this comment in particular I suspect that it might be a problem with privileges. Could it be that you run your tests as a normal(unprivileged) user but executed
taskkill
in command line window which was 'Run as Administrator' ? It might be that if you run your test from terminal started as Administrator the problem will vanish.
My windows user does not have Administrator role (all developers do not have Administrator role). So taskkill in command line were not executed under administrator privilege. Could it be node is running as sandbox and cannot kill the outside process?
Could it be node is running as sandbox and cannot kill the outside process?
This is unlikely. We start it as a regular process. That code runs this script on windows, as you can see it is simple wrapper around node.exe and the args, should not add any sandboxes.
Could it be node is running as sandbox and cannot kill the outside process?
This is unlikely. We start it as a regular process. That code runs this script on windows, as you can see it is simple wrapper around node.exe and the args, should not add any sandboxes.
New Log:
2021-04-01T13:13:14.650Z pw:browser [pid=12740][err] [12740:980:0401/091314.650:WARNING:spdy_session.cc(3403)] Received HEADERS for invalid stream 31
Close Browser: 2021-04-01 09:13:14.704
2021-04-01T13:13:14.706Z pw:browser [pid=12740]
NOTE:
When Browser start to close (
this error and log is from Microsoft Edge Chromium, when run against chrome, there are alot more in error log.
The error: "ERROR:device_event_log_impl.cc(208)] [09:13:19.365] Bluetooth: bluetooth_adapter_winrt.cc:1076 Getting Default Adapter failed" is probaly trying to access to RSA authenticatio (not sure).
I added the flag "--disable-component-update". I don't see any further update request, but it just hang without further error
Nice finding! So the autoupdate kicks in while we are closing the browser. I'm still trying to roll my change to the driver with more logging around forceful process kill but it got stuck because I found more issues that need to be fixed upstream first. Once that lands it should help us understand why taskkill cannot terminate the updater.
I landed changes with extra logging and they are now available in 1.11.0-SNAPSHOT, I'd appreciate if you could give it a try and see what the output is when running with DEBUG=pw:browser
I landed changes with extra logging and they are now available in 1.11.0-SNAPSHOT, I'd appreciate if you could give it a try and see what the output is when running with
DEBUG=pw:browser
Look like it's working. Browser.close() with 30 seconds delay, but it did closed (circle time in red). Playwright is terminated right away (previously took 30 seconds).
Hmm, this is weird. I only added more logging and expected it to fail again but a bit more details in the console. Also there are now traces of auto-update in this log so maybe it succeeded and stopped until the next update (just a wild guess) and now the browser is not hanging anymore :man_shrugging:
Hmm, this is weird. I only added more logging and expected it to fail again but a bit more details in the console. Also there are now traces of auto-update in this log so maybe it succeeded and stopped until the next update (just a wild guess) and now the browser is not hanging anymore 🤷♂️
Is there updated on the playwright node side? I find out that whenever get new playwright code, ran "./scripts/download_driver_for_all_platforms.sh -f", then rebuild my project; it behave different.
Is there updated on the playwright node side?
Yes, it was changed in the node. I see the new line (<will force kill>
) in your logs so you picked it up already.
I find out that whenever get new playwright code, ran "./scripts/download_driver_for_all_platforms.sh -f", then rebuild my project; it behave different.
This is expected, there should be no regressions though.
I just realized that you are building playwright and the driver too from source while I was assuming that you just use the version published to Maven Central. In this case you DO need to run ./scripts/download_driver_for_all_platforms.sh -f
again to fetch updated driver version and then rebuild playwright. Sorry for the misunderstanding.
I just realized that you are building playwright and the driver too from source while I was assuming that you just use the version published to Maven Central. In this case you DO need to run
./scripts/download_driver_for_all_platforms.sh -f
again to fetch updated driver version and then rebuild playwright. Sorry for the misunderstanding.
I tried to check for SNAPSHOT version but couldn't find it (see pix). If you have a branch on your github repository fork, I can tried it with your change.
I tried to check for SNAPSHOT version but couldn't find it (see pix). If you have a branch on your github repository fork, I can tried it with your change.
*-SNAPSHOT versions are served from their staging repo, to use that you need to add these lines to your pom.xml:
<repositories>
<repository>
<id>snapshots-repo</id>
<url>https://oss.sonatype.org/content/repositories/snapshots</url>
<releases><enabled>false</enabled></releases>
<snapshots><enabled>true</enabled></snapshots>
</repository>
</repositories>
But if you build from source with updated driver it should make no difference.
@ephung01 did you manage to run it with -snapshot version and collect DEBUG=pw:browser
logs it'd be very nice to nail it down while it is reproducible on your machine?
https://github.com/microsoft/playwright/pull/6232 might be helpful for this issue too
Just for reference, Below step helped to complete the process after execution.
if(browser==null) {
try {
Runtime.getRuntime().exec("taskkill /im chrome.exe /f");
} catch (IOException e) {
e.printStackTrace();
}
}
I wonder why it gives different result than what we do here: taskkill /pid <id> /T /F
Just for reference, Below step helped to complete the process after execution.
if(browser==null) { try { Runtime.getRuntime().exec("taskkill /im chrome.exe /f"); } catch (IOException e) { e.printStackTrace(); } }
blindly force to kill chrome.exe will kill other browsers that are currently execute scripts in parallel
@ephung01 did you manage to run it with -snapshot version and collect
DEBUG=pw:browser
logs it'd be very nice to nail it down while it is reproducible on your machine?
I will try it tomorrow
Just for reference, Below step helped to complete the process after execution.
if(browser==null) { try { Runtime.getRuntime().exec("taskkill /im chrome.exe /f"); } catch (IOException e) { e.printStackTrace(); } }
blindly force to kill chrome.exe will kill other browsers that are currently execute scripts in parallel
That is the reason we are checking if Condition for browser==null and then killing the browser - tested parallel execution and it works fine.
I wonder why it gives different result than what we do here:
taskkill /pid <id> /T /F
Look like 1.11.0-SNAPSHOT is not a fat jar. It missed the dependency library gson (see pix). Can you please rebuild it?
That is the reason we are checking if Condition for browser==null and then killing the browser - tested parallel execution and it works fine.
example there are 5 tests are running parallel, and one of the test is completed then execute the taskkill command to kill chrome. It would undesirably kill the chrome browser of the one the four left current running which will yield fault result. Kill by PID is the correct way to go.
Also the issue I have is that the browser is not null, but when try to close with browser.close() it hang.
That is the reason we are checking if Condition for browser==null and then killing the browser - tested parallel execution and it works fine.
example there are 5 tests are running parallel, and one of the test is completed then execute the taskkill command to kill chrome. It would undesirably kill the chrome browser of the one the four left current running which will yield fault result. Kill by PID is the correct way to go.
Also the issue I have is that the browser is not null, but when try to close with browser.close() it hang.
Thats correct ... i see sometimes this solution work and most times its not working.
Look like 1.11.0-SNAPSHOT is not a fat jar. It missed the dependency library gson (see pix). Can you please rebuild it?
It has never been a fat jar. Dependencies are pulled by maven, in particular gson is specified here. Looks like your IDE didn't update the project properly after the version was changed.
Look like 1.11.0-SNAPSHOT is not a fat jar. It missed the dependency library gson (see pix). Can you please rebuild it?
It has never been a fat jar. Dependencies are pulled by maven, in particular gson is specified here. Looks like your IDE didn't update the project properly after the version was changed.
It's my bad. I replaced the repository with the snapshot repo (https://oss.sonatype.org/content/repositories/snapshots) and accidentally override mavenCentral. That's why even I did add gson dependency but it couldn't find it (I use gradle, but there shouldn't be any different). I am testing it.
Still 30 seconds timeout and force kill. Is there any specific log you've added that you would like to look at?
Still 30 seconds timeout and force kill. Is there any specific log you've added that you would like to look at?
Yeah, the lines I was curious about are <will force kill>
and the output of taskkill
that follows after it, we were not printing that before. From the log it seems that the process is successfully killed and there should be no hanging browser processes and Browser.close()
should return after the browser process was killed. Does it match what you are seeing in debugger and in the task manager?
The question why the browser doesn't close gracefully when we send it Browser.close
command still stands but that's a separate issue from hanging browser process.
Is there any object you want me to inspect in debug mode?
Can you explain where we as I'm a bit lost. My understanding is that
Base on what I see in debug, the transport incoming Message Queue is share ford all page and frames. How is Playwright determine if it's the page or the frame that will dequeue message from the incoming Message Queue?
There is no such logic. Whatever function ends up on top of the call stack that expects a response from the server will process all messages from the incoming queue until it's condition is met. You can look at the callers of processOneMessage
to get an idea. If there are other methods on the stack that wait for a response from the server they will be handled when the stack unwinds.
Because when I am using Frame object, at this time the incoming queue already have 5 messages pending in the queue (trigger by javascript long polling from page). when the frame context try to execute querySelector, it sends the message and try to process message from the incoming queue. The pending messages (5 pending messages) get pull off the queue and process and somehow stuck in page context instead of frame context - therefore the frame context somehow never get the response of the querySelector message from incoming queue
This should work correctly. In which method on the page object does it get stuck in? Could you share relevant code, it's hard to understand what it does and where it fails?
Sorry I posted on the wrong issue (I deleted and repost this on [Question] Search element inside frame #397)
@ephung01 in #426 I made some changes that should terminate connection if the pipe to child process becomes unreadable. I hope this should help with this issue. Can you give it a try (the fix is already in the latest 1.11.0-SNAPSHOT) ?