Update geckodriver to better handle unrooted devices with non-debuggable apps
Categories
(Testing :: geckodriver, defect, P3)
Tracking
(firefox-esr78 unaffected, firefox83 unaffected, firefox84 wontfix, firefox85 wontfix, firefox86 fix-optional)
| Tracking | Status | |
|---|---|---|
| firefox-esr78 | --- | unaffected |
| firefox83 | --- | unaffected |
| firefox84 | --- | wontfix |
| firefox85 | --- | wontfix |
| firefox86 | --- | fix-optional |
People
(Reporter: bc, Unassigned)
References
(Regression)
Details
(Keywords: regression)
https://github.com/mozilla/geckodriver/issues/1808 outlined the case where geckodriver 0.28 failed to start Firefox in the case with an unrooted device running Android 8 with a non-debuggable Firefox app .
geckodriver 0.28 uses --android-storage auto by default. This attempts to determine which approach to use when automating the browser.
Currently the logic is
-
if the device is rooted, use rooted commands everywhere and place the test root in /data/local/tmp/test_root.
-
if the device is not rooted, place the test root in /data/data/<app>/test_root and use run-as to access data in /data/data/<app>/test_root. This requires that the app be debuggable and will fail if it is not. Unfortunately the error messages do not make the cause of the failure clear to users.
geckodriver 0.27 could handle the case where Android is 8 or lower with an unrooted device and a non-debuggable app since it placed the test root on /mnt/sdcard and used unrooted commands. This will definitely not work for Android 11 and may not work with 9 or 10 but we should be able to detect and handle this situation when the android storage is auto.
When we make this change to geckodriver, we will also need to make corresponding changes to mozdevice so that it will also default to unrooted commands with test root on /mnt/sdcard under the same circumstances as geckodriver.
I will file separate bugs for the geckodriver and the mozdevice parts of this change. I will work out the details using the mozdevice changes and will then be able to specify the exact behavior we need from geckodriver.
|
||
Comment 1•4 years ago
|
||
Lets keep that bug for geckodriver and just file a new dependency for mozdevice.
|
||
Updated•4 years ago
|
|
|
||
Comment 2•4 years ago
|
||
Set release status flags based on info from the regressing bug 1649094
|
|
||
Comment 3•4 years ago
|
||
We only release geckodriver from m-c, so beta is not affected.
|
|
||
Comment 4•4 years ago
|
||
Bob, mind filing the appropriate mozdevice bug? Also would you have time the next days to help getting this fixed?
|
Reporter | |
Updated•4 years ago
|
|
|
||
Comment 5•4 years ago
|
||
Bob, you added bug 1681439 as dependency for this bug, but that is all about Python changes. Did you file a similar bug for the Rust part yet?
|
|
Reporter | |
Comment 6•4 years ago
|
||
(In reply to Bob Clary [:bc] from comment #0)
I will file separate bugs for the geckodriver and the mozdevice parts of this change. I will work out the details using the mozdevice changes and will then be able to specify the exact behavior we need from geckodriver.
(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #1)
Lets keep that bug for geckodriver and just file a new dependency for mozdevice.
No I didn't. I thought you meant to just file the mozdevice bug and that geckodriver would be handled here or in bug 1680407.
|
||
Updated•4 years ago
|
|
|
||
Comment 7•4 years ago
|
||
All what we actually need to do is covered by bug 1680407 now.
|
|
||
Comment 8•4 years ago
|
||
All what we actually need to do is covered by bug 1680407 now.
Description
•