about:home shows IndexedDB interrupted errors

NEW
Unassigned

Status

Snippets
Service
3 years ago
3 years ago

People

(Reporter: mkelly, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
When the `serve_pregenerated_snippets` waffle flag is active (bug 1091939), about:home shows the following error in the console when loading snippets:

"An IndexedDB transaction that was not yet complete has been aborted due to page navigation."

The error appears to be raised by this line in aboutHome.js: http://dxr.mozilla.org/mozilla-central/source/browser/base/content/abouthome/aboutHome.js#278
(Reporter)

Comment 1

3 years ago
Upon further debugging, I find that I get this error even when the waffle flag is inactive, and even when using default snippets, so I don't think this has anything to do with the service or our snippet code.

There's bug 1083285 that added the message (previously it was a less descriptive error), and bug 1106089 for the error showing up in Firefox OS, but nothing about actually fixing whatever possible problem this is reporting on about:home, so I'm morphing this into a Firefox bug in case we need to track it down.

Same symptoms as the previous bug, message shows up on Nightly's about:home whenever you refresh, even on a new profile.
Component: Service → General
Product: Snippets → Firefox
See Also: bug 1091939bug 1083285
The about:home code is making a new readwrite transaction there, and there's no mechanism in place to wait for the transaction's "complete" event to fire. So if a user navigates away from about:home before that event has been delivered we warn about it.
(In reply to ben turner [:bent] (use the needinfo? flag!) from comment #2)

That should say:

So if a user navigates away from about:home before that event has been delivered we warn about it because the transaction might be aborted (depending on the timing). You are not be guaranteed that it was actually saved.
(Reporter)

Comment 4

3 years ago
(In reply to ben turner [:bent] (use the needinfo? flag!) from comment #3)
> (In reply to ben turner [:bent] (use the needinfo? flag!) from comment #2)
> 
> That should say:
> 
> So if a user navigates away from about:home before that event has been
> delivered we warn about it because the transaction might be aborted
> (depending on the timing). You are not be guaranteed that it was actually
> saved.

I see, I was making an assumption that the error message occurred on page load after refresh, not that it occurs when I refresh before the new page load.

I guess the question then becomes "why is about:home's indexedDB stuff taking so long?"
Summary: When snippet bundles are enabled, about:home shows IndexedDB interrupted errors → about:home shows IndexedDB interrupted errors
(In reply to Michael Kelly [:mkelly,:Osmose] from comment #4)
> I guess the question then becomes "why is about:home's indexedDB stuff
> taking so long?"

why do you think it's long time? it happens if you refresh after seconds the page is static? I'd expect it to happen if you refresh the page when it didn't finish loading. maybe it's also storing new snippets at that time.

Fwiw, this is a long standing "issue" we decided to ignore as part of the page design, cause we don't want to wait for idb to have finished before allowing the user to move away from the home page. Other similar bugs have been wontfixed, but maybe you are pointing out this is happening at unexpected times?
(Reporter)

Comment 6

3 years ago
(In reply to Marco Bonardo [::mak] (needinfo? me) from comment #5)
> why do you think it's long time? it happens if you refresh after seconds the
> page is static? I'd expect it to happen if you refresh the page when it
> didn't finish loading. maybe it's also storing new snippets at that time.
> 
> Fwiw, this is a long standing "issue" we decided to ignore as part of the
> page design, cause we don't want to wait for idb to have finished before
> allowing the user to move away from the home page. Other similar bugs have
> been wontfixed, but maybe you are pointing out this is happening at
> unexpected times?

I figured it was taking a long time because I was getting the message while refreshing the page after waiting 5-6 seconds consistently, and was curious what IndexedDB transaction was taking so long to finish.

After some further testing, I found that the messages go away if I remove all the gSnippetsMap.set function calls in the snippets JS, meaning that these are in fact being trigger by the JS from the snippets service. I'll move this bug back, and investigate if it's worth changing the snippet code to make this warning go away. Thanks for helping me understand!
Component: General → Service
Product: Firefox → Snippets
why are you calling gSnippetsMap.set from the snippets code? there should be no need to access gSnippetsMap at all, it already caches the response from the server after it loaded.
(Reporter)

Comment 8

3 years ago
(In reply to Marco Bonardo [::mak] (needinfo? me) from comment #7)
> why are you calling gSnippetsMap.set from the snippets code? there should be
> no need to access gSnippetsMap at all, it already caches the response from
> the server after it loaded.

We use it to store some data we use to filter snippets shown to the user:

1) What country they're located in based on their IP (set once a month).
2) Whether they've set up Firefox Accounts.
3) What their currently-selected search engine is.

The last two don't necessarily need gSnippetsMap to function as we query them every time anyway; it looks like the way we use them is to check for their saved value in gSnippetsMap, and then after the snippets are shown, we update them. That could probably be removed.

The first one, however, is necessary as we geolocate the user using an external service, and don't want to block snippet display by waiting for an HTTP request. Thus we use gSnippetsMap to cache the location for a month.
I see, it's being used as an abstraction to idb. yeah probably reducing set to a single call is the way to go, you could build a metadata object with everything you need and just set it once.
You need to log in before you can comment on or make changes to this bug.