941069 - revert patch 937006 once bug 937317 is landed

Status: RESOLVED INVALID

(Core :: Storage: IndexedDB, defect, P5)

Comment 1

[Andrea Marchesini [:baku]]

Attachment: crash.patch

is it time to go back to MOZ_CRASH? bug  937317 is landed.

Comment 2

[Phil Ringnalda (:philor)]

Apparently not, since now it's backed out.

Comment 3

[Bobby Holley (:bholley)]

Comment on attachment 8344165 [details] [diff] [review]
crash.patch

Hm. nsJSUtils::GetCallingLocation doesn't look at the Script Setting Stack, so this patch isn't correct on its own.

But this raises an interesting question of what, if anything, we want to happen here. The Script Settings Stack tracks incumbent globals, so that, when a non-scripted callback fires, we know which global it belongs to. And while globals generally have an origin and whatnot, that origin doesn't necessarily correspond with script filename (in the case of external scripts). And it certainly doesn't help us for line numbers.

So if we want a true (filename, line number) tuple here, I was mistaken that this would be resolved by the script settings stack, and we should WONTFIX this bug. But if it's more important to just get _something_, then we could grab the principal URI off the incumbent global (and report 0 for the line number, or something).

I suspect the answer here is probably WONTFIX. Thoughts?

Comment 4

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Something is always better than nothing.

Comment 5

[Andrew Sutherland [:asuth] (he/him)]

Most extant callsites do not seem to care about the return value, and those that do seem to only be conditionalizing setting the filename to "unknown" when unavailable and only propagating the line/column on success. No errors are reported, so mooting this bug.