1853302 - http auth popup creates a browsingContext.userPromptOpened event with type promptUserAndPass

Status: RESOLVED FIXED

(Remote Protocol :: WebDriver BiDi, defect, P2)

Description

[Julian Descottes [:jdescottes]]

STRs:

• subscribe to browsingContext.userPromptOpened
• navigate to a page with http auth

A userPromptOpened event is emitted, with an unexpected type: promptUserAndPass.

We should probably not forward the underlying prompt.type to the public event, and instead make sure that we emit one of the supported types.

I am not sure if we should emit an event for this scenario, but it looks like we don't support this type of prompt in the spec at the moment.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Hm, isn't this actually the network.authRequired event? We should probably re-route this event then by working on bug 1826198?

Comment 2

[Julian Descottes [:jdescottes]]

(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #1)

Hm, isn't this actually the network.authRequired event? We should probably re-route this event then by working on bug 1826198?

Yes probably, it's unclear to me what should happen once we have implemented bug 1826198. But then, what is the behavior if we are not listening to authRequired? It sounds like on top of supporting the event we also need to have some strategy to deal with those popups.

And in general this also shows we are directly passing through prompt types from the platform, which we shouldn't do.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to Julian Descottes [:jdescottes] from comment #2)

Yes probably, it's unclear to me what should happen once we have implemented bug 1826198. But then, what is the behavior if we are not listening to authRequired? It sounds like on top of supporting the event we also need to have some strategy to deal with those popups.

Isn't that the same problem as when not being subscribed to the browsingContext.userPromptOpened and a new prompt gets opened?

And in general this also shows we are directly passing through prompt types from the platform, which we shouldn't do.

Yes, that is what we need to fix. We should have a switch statement that can correctly forward the events to a given module, and ignore all that are unsupported. Maybe that's what we should do for this bug?

Comment 4

[Julian Descottes [:jdescottes]]

(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #3)

(In reply to Julian Descottes [:jdescottes] from comment #2)

Yes probably, it's unclear to me what should happen once we have implemented bug 1826198. But then, what is the behavior if we are not listening to authRequired? It sounds like on top of supporting the event we also need to have some strategy to deal with those popups.

Isn't that the same problem as when not being subscribed to the browsingContext.userPromptOpened and a new prompt gets opened?

It's very similar yes. What I meant is that it's not guaranteed that this problem will go away when we implement the event. We might just implement the event without preventing auth prompts when not subscribed to the event.

And in general this also shows we are directly passing through prompt types from the platform, which we shouldn't do.

Yes, that is what we need to fix. We should have a switch statement that can correctly forward the events to a given module, and ignore all that are unsupported. Maybe that's what we should do for this bug?

SGTM (that was the original intent in the summary, sorry if that was unclear)

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to Julian Descottes [:jdescottes] from comment #4)

Isn't that the same problem as when not being subscribed to the browsingContext.userPromptOpened and a new prompt gets opened?

It's very similar yes. What I meant is that it's not guaranteed that this problem will go away when we implement the event. We might just implement the event without preventing auth prompts when not subscribed to the event.

Exactly, and this would certainly warrant a new bug and probably a BiDi spec issue. Maybe prompts should be discarded by default if no handler is subscribed for the related events.

Comment 6

[James Graham [:jgraham]]

In general what we should do with non-alert type blocking prompts is not well defined.

In the short term we should certainly remove this nonstandard event, before someone starts to depend on it.

In the medium term, having an event for this and similar cases probably makes sense (c.f. file uploads which can create a file picker dialog). Auto-dismissing doesn't make sense for some use cases (e.g. connecting an editor to the browser). However having something like classic's user prompt handler to allow some clients to opt-in to never displaying a blocking prompt without having to handle each one explicitly might also make sense.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Lets add to M8 so that we can get the short-term fix landed. Julian, please file the follow-up bug as well. Thanks.

Comment 8

[Alexandra Borovova [:Sasha]]

Attachment: Bug 1853302 - [bidi] Do not send browsingContext.userPromptOpened event for unsupported prompt types.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/49c204d9c4fb
[bidi] Do not send browsingContext.userPromptOpened event for unsupported prompt types. r=webdriver-reviewers,whimboo

Comment 10

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/49c204d9c4fb

Comment 11

[Julian Descottes [:jdescottes]]

(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #7)

Lets add to M8 so that we can get the short-term fix landed. Julian, please file the follow-up bug as well. Thanks.

Filed bug 1853903