FrameTransport._getBrowsingContexts() is not compatible with GeckoView
Categories
(Remote Protocol :: WebDriver BiDi, task)
Tracking
(Not tracked)
People
(Reporter: whimboo, Unassigned)
Details
With my upcoming patch on bug 1749444 we can run Wdspec jobs on Android. Running them locally I can see timeouts for all the ConsoleLogEntry
tests:
/webdriver/tests/bidi/log_entry_added/console.py
TIMEOUT /webdriver/tests/bidi/log_entry_added/console.py
/webdriver/tests/bidi/log_entry_added/console_args.py
TIMEOUT /webdriver/tests/bidi/log_entry_added/console_args.py
/webdriver/tests/bidi/log_entry_added/event_buffer.py
TIMEOUT /webdriver/tests/bidi/log_entry_added/event_buffer.py
Triggering the console API calls via Execute Script
works, but no event is emitted to the BiDi client. I cannot see any error in adb logcat.
As given by Agi the same observer should be used.
Reporter | ||
Comment 1•3 years ago
|
||
There is an interesting difference between desktop and mobile which explains why no log events are emitted:
Desktop:
0:24.90 pid:47108 1644428759755 RemoteAgent TRACE Module root/log.jsm found for ROOT
0:24.90 pid:47108 *** root log subscribe
0:24.90 pid:47108 1644428759757 RemoteAgent TRACE Received command log._applySessionData for destination WINDOW_GLOBAL
0:24.90 pid:47108 1644428759757 RemoteAgent TRACE Module windowglobal-in-root/log.jsm found for WINDOW_GLOBAL
0:24.91 pid:47108 1644428759764 RemoteAgent TRACE Created MessageHandler WINDOW_GLOBAL for session 27e103d7-0daf-41e8-97d8-5fc8cda8563b
0:24.91 pid:47108 1644428759764 RemoteAgent TRACE Received command log._applySessionData for destination WINDOW_GLOBAL
0:24.91 pid:47108 1644428759767 RemoteAgent TRACE Module windowglobal/log.jsm found for WINDOW_GLOBAL
0:24.91 pid:47108 *** start listening for log.entryAdded
0:24.91 pid:47108 ** Registered console-api-log-event observer
0:24.91 pid:47108 1644428759768 WebDriver BiDi DEBUG 27e103d7-0daf-41e8-97d8-5fc8cda8563b <- {"id":1,"result":{}}
Mobile:
02-09 18:21:09.967 6397 6412 I Gecko : 1644427269967 RemoteAgent TRACE Module root/log.jsm found for ROOT
02-09 18:21:09.967 6397 6412 I Gecko : *** root log subscribe
02-09 18:21:09.970 6397 6412 I Gecko : 1644427269970 RemoteAgent TRACE Received command log._applySessionData for destination WINDOW_GLOBAL
02-09 18:21:09.971 6397 6412 I Gecko : 1644427269971 RemoteAgent TRACE Module windowglobal-in-root/log.jsm found for WINDOW_GLOBAL
02-09 18:21:09.972 6397 6412 I Gecko : 1644427269972 WebDriver BiDi DEBUG e51db9e3-8ceb-4ed0-87da-8bd3a2b75cb0 <- {"id":1,"result":{}}
While windowglobal-in-root/log.jsm
is still found in the mobile case, we do not load the windowglobal/log.jsm
module. Reason for that is that we never get a JSWindowActor pair for our registered MessageHandlerFrameActor.
Agi, do you have an explanation of why the actor pairs aren't getting created for the tab that is open?
Reporter | ||
Comment 2•3 years ago
|
||
Note that this is not just for the initial about:blank
page that gets loaded but for each and every page:
1:21.34 pid:74454 1644484966411 webdriver::server DEBUG -> POST /session/1c7975b2-c8e2-4294-ac93-ffb070c5326a/url {"url": "http://web-platform.test:8000/webdriver/tests/support/inline.py?doc=%3C%21doctype+html%3E%0A%3Cmeta+charset%3DUTF-8%3E%0A%3Cdiv%3Efoo&mime=text%2Fhtml&charset=UTF-8"}
1:21.64 pid:74454 1644484966710 webdriver::server DEBUG <- 200 OK {"value":null}
1:21.74 pid:74454 1644484966807 webdriver::server DEBUG -> POST /session/1c7975b2-c8e2-4294-ac93-ffb070c5326a/execute/sync {"script": "console.log('TEST')", "args": []}
1:21.81 pid:74454 1644484966877 webdriver::server DEBUG <- 200 OK {"value":null}
2:34.29 TEST_END: TIMEOUT, expected OK
So something might maybe special with the browser in mobile builds so that we never getting the actors created.
Reporter | ||
Comment 3•3 years ago
|
||
As it turned out we currently only check windows of type navigator:browser
with gBrowser
available:
This is clearly not compatible with other applications. As such we should have a new method in TabManager
which would allow us to retrieve all the available content browsers in all open browser windows.
Reporter | ||
Comment 4•3 years ago
|
||
There is actually an existing bug 1723919 which covers exactly this problem, and that we totally missed!
Description
•