Closed Bug 1846343 Opened 10 months ago Closed 8 months ago

TabManager.getNavigableForBrowsingContext() fails when passed in browsing context is null

Categories

(Remote Protocol :: Agent, defect, P2)

defect
Points:
3

Tracking

(firefox119 fixed)

RESOLVED FIXED
119 Branch
Tracking Status
firefox119 --- fixed

People

(Reporter: whimboo, Assigned: jdescottes)

References

(Blocks 2 open bugs)

Details

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

Attachments

(5 files)

We immediately check for browsingContext.isContent but do no null check before.

https://searchfox.org/mozilla-central/rev/e4fa79ba05364da0d6ec40d3f9dbe0d15ce6f902/remote/shared/TabManager.sys.mjs#267-270

Most likely we want to return null here as well when the browsing context is null.

Blocks: 1845225

Note that call sites will have to handle null anyway. Either they should check the browsing context before calling getNavigableForBrowsingContext or they need to null check the returned navigable.

I think I would rather keep failing in getNavigableForBrowsingContext, maybe with a clearer failure. For instance, when looking at the NavigationManager, returning null might lead to unexpected side effects. Eg we can end up using null as a key in our internal map, which might make things hard to investigate.

We have other APIs like getBrowserForTab(), getTabBrowser(), getBrowserById, and others that return null if the related argument is null as well. So maybe we should keep all these APIs in sync and return null here as well and not a failure?

Severity: -- → S3
Priority: -- → P3

Looking a bit at the APIs listed above:

  • getTabBrowser will throw if win is null
  • getBrowserById is a different kind of API, we never null check id, but a null id will be treated similarly to passing an outdated id.

getIdForBrowsingContext and getIdForBrowser consistently check against null, but that leads to bugs such as https://bugzilla.mozilla.org/show_bug.cgi?id=1847563

I don't really have a strong opinion, as long as we make sure to update the callsites to handle the null or error case properly.

Right. Does it mean this bug blocks bug 1847563? I'm happy to provide a fix here so that we can better check for a non-existent navigable.

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

Right. Does it mean this bug blocks bug 1847563? I'm happy to provide a fix here so that we can better check for a non-existent navigable.

Yes, it sounds fine to block. We can apply whatever pattern we use here for getNavigableForBrowsingContext to Bug 1847563 and getIdForBrowsingContext. (or we can also review all TabManager APIs and all consumers in this bug)

Blocks: 1847563
Points: --- → 3
Priority: P3 → P2
Whiteboard: [webdriver:m8]
Assignee: nobody → jdescottes
Status: NEW → ASSIGNED

As discussed, let's focus on getNavigableForBrowsingContext here, and file follow up bugs for other APIs in order to apply a similar pattern.

Blocks: 1850961
Pushed by jdescottes@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5ccc87553d19
[remote] Throw an error when getNavigableForBrowsingContext() is called with an invalid context r=webdriver-reviewers,whimboo
https://hg.mozilla.org/integration/autoland/rev/4875bf7eeb5b
[remote] Check for valid browsing context in NavigationManager getNavigationForBrowsingContext r=webdriver-reviewers,whimboo
https://hg.mozilla.org/integration/autoland/rev/f03aef4971b2
[remote] Do not emit network events for discarded browsing contexts r=webdriver-reviewers,whimboo
https://hg.mozilla.org/integration/autoland/rev/128da1e1606f
[remote] Check for valid browsing context in Session getSeenNodesForBrowsingContext r=webdriver-reviewers,whimboo
https://hg.mozilla.org/integration/autoland/rev/2e2b8c5f6818
[remote] Catch type errors for navigation messages from child actors r=webdriver-reviewers,whimboo
Blocks: 1852508
Blocks: 1852509
Whiteboard: [webdriver:m8] → [webdriver:m8][webdriver:relnote]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: