Closed Bug 2033769 Opened 4 months ago Closed 3 months ago
Remote Protocol
Marionette
defect
P3
S3
Points:
2
RESOLVED FIXED
152 Branch
| Tracking | Status | |
|---|---|---|
| firefox152 | --- | fixed |
When trying to navigate to a page that would cause an error to be thrown within lazy.navigate.navigateTo() we currently completely miss this error because this method is marked async and we do not return the Promise here:
As such the code in lazy.navigate.waitForNavigationCompleted() is not going to wait for the Promise to be resolved and we silently ignore the error.
Solution should add a return statement to the code above to ensure we always return a value but also we can change lazy.navigate.navigateTo() to not be async.
Not sure how to actually trigger that situation given that we already filter out invalid URLs before we start to navigate. At least for now I can see it with my upcoming patch for bug 1579790.
The WebDriver:Refresh command is affected as well. But in both cases it's currently unlikely that this particular code path is hit.
Summary: Unexpected behavior for "WebDriver:Navigate" when calling "lazy.navigate.navigateTo()" causes an error → Ignored error in "WebDriver:Navigate" and "WebDriver:Refresh" when triggering the actual navigation fails
Assignee: nobody → hskupin
Status: NEW → ASSIGNED
Flags: needinfo?(hskupin)
Flags: needinfo?(hskupin)
Severity: -- → S3
Points: --- → 2
Priority: -- → P3
Whiteboard: [webdriver:m20]
Attachment #9572848 - Attachment description: Bug 2033769 - [marionette] Use sessionHistory.reload() only when history items exist. → Bug 2033769 - [remote] Use sessionHistory.reload() only when history items exist.
Flags: needinfo?(hskupin)
I think we might want to try sessionHistory?.count && sessionHistory?.index >= 0 instead of sessionHistory?.count && sessionHistory?.index > 0. If the context is on its first URL sessionHistory.count === 1 and sessionHistory.index === 0, but we should still be able to use this in order to reload via session history.
Hopefully that also works fine for /ink-overflow-001-print.html
Thanks Julian. Yes, that makes total sense. Not sure why I used > 0 in this case. Nevertheless I do not understand why I'm not getting this affected wdspec test to fail locally while it's perma failing in CI.
Flags: needinfo?(hskupin)
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 152 Branch
Whiteboard: [webdriver:m20] → [webdriver:m20][webdriver:relnote]