domstringlist.html wpt test fails with harness error in Firefox but not Chrome due to IndexedDB exception

RESOLVED FIXED in Firefox 58



2 years ago
a year ago


(Reporter: ayg, Assigned: baku)



Firefox Tracking Flags

(firefox58 fixed)



(1 attachment, 1 obsolete attachment)

It seems like the call is returning an AbortError in such a fashion that it's caught by the global error handler in the same way as an uncaught exception, even though an onerror handler is specified on a subsequent line.  Chrome and Edge don't do this.  What's happening?

This seems related to bug 1120178 comment #5.
Jan, please take a look.
Flags: needinfo?(jvarga)
Priority: -- → P3
Looks like the issue is that idbfactory errors are always reported on the window if the thing they were fired on does not preventDefault.  See IndexedDatabaseManager::CommonPostHandleEvent and sgo->HandleScriptError() call in there.

We also fire error events on the global in workers, looks like.

I don't see anything in the idb spec saying we should do that, and it's not clear to me why we're doing it.
Andrea, do you know what the error reporting story here is and why we do it?
Flags: needinfo?(amarchesini)

Comment 4

a year ago
> We also fire error events on the global in workers, looks like.
> I don't see anything in the idb spec saying we should do that, and it's not
> clear to me why we're doing it.

This seems old code. Wondering if the spec was saying that before indexedDB-2.
I take this bug.
Assignee: nobody → amarchesini
Flags: needinfo?(amarchesini)

Comment 5

a year ago
Created attachment 8912144 [details] [diff] [review]
Flags: needinfo?(jvarga)
Attachment #8912144 - Flags: review?(bugmail)
Comment on attachment 8912144 [details] [diff] [review]

:bevis, it looks like your work on bug 1274938 and the spec discussion on that you're involved with is still relevant, so I'm transferring this review to you.

One thing worth noting is that even if we want to remove the window.onerror firing at content, this also removes the ScriptErrorHelper::Dump() that I think in various cases has helped us diagnose weird IDB problems.  We should make sure we've got IDB_WARNING paths for everything we care about if removing it.
Attachment #8912144 - Flags: review?(bugmail) → review?(btseng)
Comment on attachment 8912144 [details] [diff] [review]

Review of attachment 8912144 [details] [diff] [review]:

The implementation was done in bug 607729 and the only information I have is on bug 1274938 comment 6 before :sicking leaved. :\
This feature seems wanted for a long time by both Chrome/Firefox according to but we didn't have it specified in v2(the milestone now is set to v3).

Instead of removing the implementation entirely, I'd prefer to have a preference to enable firing (window|self).onerror in
and the default value of this preference is false for now.

Then, we could still have error printed in the error console for developers to debug:

Does this make sense to you?
Attachment #8912144 - Flags: review?(btseng)

Comment 9

a year ago
Created attachment 8912529 [details] [diff] [review]

Do you mind to file a spec issue?
Attachment #8912144 - Attachment is obsolete: true
Attachment #8912529 - Flags: review?(btseng)
Comment on attachment 8912529 [details] [diff] [review]

Review of attachment 8912529 [details] [diff] [review]:

Thanks! BTW, the spec issue is already available in
Attachment #8912529 - Flags: review?(btseng) → review+
Ok, thanks for fixing this.

Comment 12

a year ago
Pushed by
IDB should not propagate the error events to self.onerror, r=bevis

Comment 13

a year ago
Last Resolved: a year ago
status-firefox58: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
You need to log in before you can comment on or make changes to this bug.