Closed Bug 1853302 Opened 6 months ago Closed 6 months ago

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

Categories

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

defect
Points:
1

Tracking

(firefox119 fixed)

RESOLVED FIXED
119 Branch
Tracking Status
firefox119 --- fixed

People

(Reporter: jdescottes, Assigned: Sasha)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [webdriver:m8][webdriver:relnote])

Attachments

(1 file)

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.

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

(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.

(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?

(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)

(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.

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.

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

Points: --- → 1
Flags: needinfo?(jdescottes)
Priority: -- → P2
Whiteboard: [webdriver:m8]
Blocks: 1853903
Assignee: nobody → aborovova
Status: NEW → ASSIGNED
Pushed by aborovova@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/49c204d9c4fb
[bidi] Do not send browsingContext.userPromptOpened event for unsupported prompt types. r=webdriver-reviewers,whimboo
Status: ASSIGNED → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → 119 Branch

(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

Flags: needinfo?(jdescottes)
Whiteboard: [webdriver:m8] → [webdriver:m8][webdriver:relnote]
You need to log in before you can comment on or make changes to this bug.