TabManager.getNavigableForBrowsingContext() fails when passed in browsing context is null
Categories
(Remote Protocol :: Agent, defect, P2)
Tracking
(firefox119 fixed)
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.
Most likely we want to return null
here as well when the browsing context is null.
Assignee | ||
Comment 1•2 years ago
|
||
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.
Reporter | ||
Comment 2•2 years ago
|
||
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?
Assignee | ||
Comment 3•2 years ago
|
||
Looking a bit at the APIs listed above:
getTabBrowser
will throw ifwin
is nullgetBrowserById
is a different kind of API, we never null checkid
, but anull
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.
Reporter | ||
Comment 4•2 years ago
|
||
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.
Assignee | ||
Comment 5•2 years ago
|
||
(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)
Reporter | ||
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 6•2 years ago
|
||
As discussed, let's focus on getNavigableForBrowsingContext
here, and file follow up bugs for other APIs in order to apply a similar pattern.
Assignee | ||
Comment 7•2 years ago
|
||
Assignee | ||
Comment 8•2 years ago
|
||
Depends on D187476
Assignee | ||
Comment 9•2 years ago
|
||
Depends on D187477
Assignee | ||
Comment 10•2 years ago
|
||
Depends on D187478
Assignee | ||
Comment 11•2 years ago
|
||
Depends on D187479
Comment 12•2 years ago
|
||
Comment 13•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/5ccc87553d19
https://hg.mozilla.org/mozilla-central/rev/4875bf7eeb5b
https://hg.mozilla.org/mozilla-central/rev/f03aef4971b2
https://hg.mozilla.org/mozilla-central/rev/128da1e1606f
https://hg.mozilla.org/mozilla-central/rev/2e2b8c5f6818
Reporter | ||
Updated•2 years ago
|
Description
•