After switching remote frame, the uuid of the element has changed

RESOLVED DUPLICATE of bug 1311041

Status

defect
RESOLVED DUPLICATE of bug 1311041
4 years ago
2 years ago

People

(Reporter: martijn.martijn, Assigned: ato)

Tracking

(Blocks 1 bug, {pi-marionette-server})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Reporter

Description

4 years ago
See patch, steps to reproduce:
- Apply patch, then run the following tests:

./mach marionette-test testing/marionette/client/marionette/tests/unit/test_switch_frame.py
b86c8577-33aa-334e-a4b9-dfd0dbe826f9
b86c8577-33aa-334e-a4b9-dfd0dbe826f9

./mach marionette-test testing/marionette/client/marionette/tests/unit/test_switch_remote_frame.py
343cdbbe-a881-d248-ad7b-e89d18d322e8
f77330f7-a3d8-7042-ba38-135a29394000

Note how after switching to a remote frame, then going back, makes the same element on the page get a different uuid, while this doesn't happen in the same-process iframe.
Assignee

Updated

4 years ago
Assignee

Comment 1

4 years ago
We need to retain the element manager for each browsing context for the duration of the top-level browsing context.  I suspect we are discarding it some point.
Assignee

Comment 2

3 years ago
I spoke to AutomatedTester earlier and I suspect that because the window handle ID changes when the browser experiences a remoteness change, we don’t find back to the original element store for the second lookup.  This would explain why one would get a different UUID only after switching to/from a remote frame.
Assignee: nobody → ato
Status: NEW → ASSIGNED
Assignee

Comment 3

2 years ago
You could argue this is a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1311041.
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: marionette-window-tracking
You need to log in before you can comment on or make changes to this bug.