Status Update
No update yet.
Comments
sa...@gmail.com
sa...@gmail.com
sa...@pkshatech.com
This issue does not occur with Chromedriver 133.0.6835.0. It behaves the same as Chromedriver 132.
ka...@google.com
Requesting dev team please look into this issue.
Thanks,
li...@gmail.com
Wasn't happening in Chrome v132.
de...@gmail.com
Also when trying to create a screenshot using DevTools when a PDF is open the entire browser crashes. Noticed issue on regular and beta channel for Chrome 133.
eu...@gmail.com
Does anyone know of any progress on this issue?
Once 135 is released, the 133 web drivers that are not causing problems will no longer be available.
I am hoping this issue will be resolved by the time of the 135 release.
Here are the details I have researched
====
This version does not issue two windowHandle when opening pdf tabs
This version issues two
As far as I can tell, there are no commits between the two versions.
as far as I could tell. Could this be related to this issue?
Hope this issue is resolved soon, thanks!
al...@google.com
al...@google.com
I'm not able to reproduce the issue. I've added a regression test that covers the PDF opening scenario here:
Could you retest and let me know if this is still reproducible?
eu...@gmail.com
after v133.0.6895.0, The background page of the Chrome PDF Viewer, which was previously excluded, is now displayed in the WindowHandles, and when this is the target of manipulation, an error occurs
handle: C119A4AEB32D616C2B02BE599E77EFDD
title: 7a79c35f7ce0704dec63be82440c8182.pdf
URL: chrome-extension://mhjfbmdgcfjbbpaeojofohoefgiehjai/index.html
This has been fixed again, but pdf viewers and some extensions still recognize background tabs.
ex.)
simple validation script→WebTest.kt
execute by 133.0.6893.0→before133.log
execute by 135.0.7049.3(use beta chrome)→after133.log
dm...@nixs.com
The issue is still reproducible. It seems like an extra handle appears with a delay. In my case, I added a 100ms wait before checking the size of .getWindowHandles().
eu...@gmail.com
The sample code contained personal information, so I fixed it.
db...@smartware.pl
I had the same problem for about a month. It started after Chrome version 133 was released, and it's still happening in version 134. When I start my regression test, everything works fine in a window. But when I click a button that should open a new tab with a PDF file inside, I get an issue. The PDF opens in a new tab, as it should, but when I use the 'driver.getWindowHandles()' method, Selenium sees three tabs, one of which is hidden. Is there a problem with Chrome version or Selenium? When can this be fixed? It's really frustrating, because we have to redo a lot of the regression tests.
Daniel
al...@google.com
al...@google.com
This seems to come down to PdfOopif experiment being disabled during test, resulting in a guest window that's not filtered out from top level targets. That might explain why I wasn't able to reproduce this issue in the earlier regression test.
To confirm I've narrowed it down to the correct issue, would you be able to attach a verbose protocol log from ChromeDriver?
ta...@pkshatech.com
eu...@gmail.com
I've attached the Driver logs. Please check them. These are logs from when the script I attached earlier was executed.
al...@google.com
Thanks for attaching the log. Fairly confident that it's the same issue; will proceed with the CL and see if that fixes it.
dx...@google.com
Project: chromium/src
Branch: main
Author: Alex N. Jose
Link:
Discard guest webview tab targets from top level
Expand for full commit details
PdfOopif feature when disabled opens PDFs in a guestview and an
associated tab target. This wasn't getting filtered from top level views
determination. This CL expands the filter to chrome-extension prefix to
mitigate. Also adds associated regression tests for PdfOopif disabled
state as well as Mv3 chrome extension that creates tabs.
Bug: 396611138
Change-Id: Ibaf1df4696d86d982a52dd24535233d24e34187e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6383500
Commit-Queue: Alex N. Jose <alexnj@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1439735}
Files:
- M
chrome/test/chromedriver/chrome/web_view_info.cc - M
chrome/test/chromedriver/test/run_py_tests.py - A
chrome/test/data/chromedriver/extv3_new_tab/background.js - A
chrome/test/data/chromedriver/extv3_new_tab/manifest.json
Hash: 3f17a91a25399143a62ac06d0ba105f8a5bc4351
Date: Fri Mar 28 22:18:38 2025
al...@google.com
eu...@gmail.com
Thank you, will this be reflected in the latest version of 135?
lu...@dexters.co.uk
Selenium WebDriver - Ruby Bindings - 4.29.0
Chrome v134
Test (Pseudo code)
```
1) Load up page 1
2) Load up page 2 (This is an interactive view of a PDF)
3) Run teardown in capybara (Ruby wrapper for selenium), that calls driver.reset! and iteratively switches through each window
4) Selenium::WebDriver::Error::NoSuchWindowError is thrown
```
Ping #9 I know you mentioned you had a PDF test not failing. I have a PDF test that fails
al...@google.com
The fix landed in 136.0.7097.0.
eu...@gmail.com
Can you apply it to 135?
ch...@google.com
All Chrome DevTools regression bugs must be verified and the milestones in which these where found and verified must be recorded in the Found In and Verified In fields respectively. This issue was closed as Fixed but doesn't have milestone information in the Found In and Verified In fields. Please verify that the issue is fixed and record the milestones in the Found In and Verified In fields. See go/chrome-devtools/regressions for details about the process.
Thanks for your time! To disable nags, add Disable-Nags (case sensitive) to the Chromium Labels custom field.
al...@google.com
ch...@google.com
All Chrome DevTools regression bugs must be verified and the milestones in which these where found and verified must be recorded in the Found In and Verified In fields respectively. This issue was closed as Fixed and has milestone information in both the Found In and Verified In fields, so changing the status to Fixed (Verified). See go/chrome-devtools/regressions for details about the process.
ch...@google.com
The Found In field may only contain numeric values. Some values were corrected. You can see the changes by toggling full history on the issue.
Description
Steps to reproduce the problem
Problem Description
if you open a pdf file in a new tab it creates two window handles instead of just one. This can cause an unknown_error to occur if you switch the current handle to wrong handle and then try to call webdriver.close() on the wrong one. In Chrome 132 opening a pdf in a new tab will only create one new window_handle.
Summary
Chromedriver 133 creates an extra window handle when opening a pdf in a new tab
Additional Data
Category: Developer Tools
Chrome Channel: Stable
Regression: Yes