Perma Android Fission /webdriver/tests/element_click/navigate.py | test_link_from_nested_context_with_target[_top] - webdriver.error.UnknownErrorException: unknown error (500): InactiveActor: Actor is no longer active
Categories
(Remote Protocol :: Marionette, defect, P3)
Tracking
(Not tracked)
People
(Reporter: jdescottes, Unassigned)
References
()
Details
(Keywords: intermittent-failure, Whiteboard: [fission:android:m2])
Attachments
(1 obsolete file)
+++ This bug was initially created as a clone of Bug #1786640 +++
Filed by: istorozhko [at] mozilla.com
Parsed log: https://treeherder.mozilla.org/logviewer?job_id=387806546&repo=try
Full log: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/UM5JCZ5oTnOpQIDzteY_TQ/runs/0/artifacts/public/logs/live_backing.log
Here is the link to the try push: https://treeherder.mozilla.org/jobs?repo=try&revision=912cffe26463c17323a7b00ac5c07ceff88409a7
This bug blocks Fission on Android. The tests were run on Fission with `isolateNothing` strategy (so when debugging locally or making new try pushes, please add `pref("fission.webContentIsolationStrategy", 0);` line to the `geckoview-prefs.js`)
| Reporter | ||
Comment 1•3 years ago
|
||
We want to close Bug #1786640 as we completed the investigation there. I will summarize the findings and move the pending need-infos here.
| Reporter | ||
Updated•3 years ago
|
| Reporter | ||
Comment 2•3 years ago
|
||
Quick context about test_link_from_nested_context_with_target[_top]. This test loads a page which contains an iframe with a link using target=_top. Clicking on the link will therefore make the top page navigate.
The test checks that we can still find elements in the top page after the navigation. However Marionette gets confused on Android with Fission, because we get a XULFrameLoaderCreated event for the top page when we navigate. With the way the test is written, this happens right in the middle of another marionette command where we try to "switch_to_frame" to go from the iframe back to the top context.
So there is definitely an issue in Marionette when a XULFrameLoaderCreated event happens in the middle of a switchToFrame. However we don't get into this issue on Desktop because there is no XULFrameLoaderCreated emitted for this scenario. I assume this means that on Android with Fission, the browsing context is replaced in this situation, while this is not the case on desktop?
owlish, smaug: Any idea why we have this difference between Android and Desktop?
To be clear: we should fix the Marionette issue, but we want to clarify first if the behavior on Andoid is expected or if it's a bug.
Thanks!
Comment 3•3 years ago
|
||
What kind of page does the top level bc have first and what is being loaded there by the test?
Does the page perhaps not get bfcached on desktop, but it does on Android? (because unload event listener don't block using bfcache on Android)
| Reporter | ||
Comment 4•3 years ago
•
|
||
(In reply to Olli Pettay [:smaug][bugs@pettay.fi] from comment #3)
What kind of page does the top level bc have first and what is being loaded there by the test?
Does the page perhaps not get bfcached on desktop, but it does on Android? (because unload event listener don't block using bfcache on Android)
The page before:
<html>
<head><meta charset="UTF-8">
</head><body><iframe src="http://web-platform.test:8000/webdriver/tests/support/inline.py?doc=%3C%21doctype+html%3E%0A%3Cmeta+charset%3DUTF-8%3E%0A%3Ca+href%3D%27http%3A%2F%2Fweb-platform.test%3A8000%2Fwebdriver%2Ftests%2Fsupport%2Finline.py%3Fdoc%3D%253C%2521doctype%2Bhtml%253E%250A%253Cmeta%2Bcharset%253DUTF-8%253E%250A%253Cp%2Bid%253D%2527foo%2527%253Efoo%253C%252Fp%253E%26mime%3Dtext%252Fhtml%26charset%3DUTF-8%27+target%3D%27_top%27%3Eclick%3C%2Fa%3E&mime=text%2Fhtml&charset=UTF-8"></iframe></body>
</html>
The iframe content in a more readable form:
<html>
<head><meta charset="UTF-8"></head>
<body>
<a href="http://web-platform.test:8000/webdriver/tests/support/inline.py?doc=%3C%21doctype+html%3E%0A%3Cmeta+charset%3DUTF-8%3E%0A%3Cp+id%3D%27foo%27%3Efoo%3C%2Fp%3E&mime=text%2Fhtml&charset=UTF-8" target="_top">click</a>
</body>
</html>
The page after the navigation:
<html><head><meta charset="UTF-8">
</head><body><p id="foo">foo</p></body></html>
I'll build a separate test case.
| Reporter | ||
Updated•3 years ago
|
| Reporter | ||
Comment 5•3 years ago
•
|
||
The page at https://bug1816061-testcase.glitch.me/ reproduces the same scenario as the test. But after building it and testing manually, I was seeing the same event both in Desktop and Android. Going back to the web platform test, on Desktop there is no "XULFrameLoaderCreated" event only if the click is simulated by webdriver. If instead I click manually on the link, there is a "XULFrameLoaderCreated" event.
So it seems like the difference is rather in the way marionette simulates a click on desktop vs android?
| Reporter | ||
Updated•3 years ago
|
Updated•3 years ago
|
Comment 6•3 years ago
|
||
The product::component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.
Updated•3 years ago
|
Updated•3 years ago
|
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
Comment 9•2 years ago
|
||
Hi folks, can we bump the priority of this? It blocks Android Fission
| Reporter | ||
Comment 11•2 years ago
|
||
I will rebase and update my patch from Bug 1817820, this should fix this issue.
| Reporter | ||
Comment 12•2 years ago
|
||
Comment 13•2 years ago
|
||
The severity field for this bug is set to S4. However, the following bug duplicate has higher severity:
- Bug 1817820: S3
:whimboo, could you consider increasing the severity of this bug to S3?
For more information, please visit BugBot documentation.
| Reporter | ||
Updated•2 years ago
|
Comment 14•2 years ago
|
||
Comment on attachment 9398669 [details]
Bug 1816061 - [marionette] Retry switch to frame if browsing context changed mid flight
Revision D208638 was moved to bug 1817820. Setting attachment 9398669 [details] to obsolete.
Comment 15•2 years ago
|
||
Julian, will you follow-up with a patch to remove the manifest file? Looks like we forgot to do that over on bug 1817820.
Comment 16•2 years ago
|
||
Sorry, my bad. I mixed it up with the other fission related bug. I assume we can already mark as fixed?
| Reporter | ||
Updated•2 years ago
|
| Reporter | ||
Comment 17•2 years ago
|
||
Yes we should be good here, closing!
Updated•2 years ago
|
Description
•