Implement user prompt handler

NEW
Unassigned

Status

Testing
Marionette
P1
normal
a year ago
18 days ago

People

(Reporter: ato, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug, {ateam-marionette-server})

Version 3
ateam-marionette-server
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

a year ago
The WebDriver specification has a concept of a user prompt handler (http://w3c.github.io/webdriver/webdriver-spec.html#dfn-handle-any-user-prompts) that Marionette currently does not implement.  We must implement it to be WebDriver compatible.

The idea is that you can set a handler state that will automatically run an action tied to said state when a user prompt is present.
(Reporter)

Updated

a year ago
Blocks: 721859
Keywords: ateam-marionette-server
(Reporter)

Updated

4 months ago
Depends on: 1359004
Comment hidden (offtopic)
Priority: -- → P1
Depends on: 1311041
David, why do you think it is dependent on bug 1311041?
Flags: needinfo?(dburns)
because its going to be simpler to implement when 1311041 is complete.
Flags: needinfo?(dburns)
Tab modal prompts are not tight to window ids but to the window it lives in. And those we track perfectly because the listener registers itself and as such we register for the modal dialog observer notification. So bug 1311041 is not a hard blocker, and currently I don't see what could make it simpler.
(Reporter)

Comment 5

18 days ago
(In reply to Henrik Skupin (:whimboo) from comment #4)

> Tab modal prompts are not tight to window ids but to the window
> it lives in.  And those we track perfectly because the listener
> registers itself and as such we register for the modal dialog
> observer notification. So bug 1311041 is not a hard blocker, and
> currently I don't see what could make it simpler.

I guess I don’t really understand what you’re saying here, but
Marionette currently keeps exactly one reference to the last modal
dialogue to appear.  This means we don’t track modals on a per-tab
level, which we need to do because it is possible to switch to and
interact with other tabs.

In my opinion the current code we have for tracking user prompts is
far too complicated.  We could do away with keeping a reference to
the modal, and also stop tracking global modal dialogues because
they are not used when interacting with web content.

The implementation of a specification conforming user prompt handler
is not impossible without bug 1311041, but easier with it because
each browsing context would have a unique abstraction, as opposed to
the way curBrowser works right now.
You need to log in before you can comment on or make changes to this bug.