Extension doesn't work after first logging in

kav2k / fl_favourites

Playing Favourites for Fallen London

MIT License

8 stars 11 forks source link

Extension doesn't work after first logging in #7

Closed matthew-cline closed 7 years ago

matthew-cline commented 8 years ago

After first logging into Fallen London the extension has no effect. I have to reload the page for the green ribbons to show up.

I'm using Chrome 49.0.2623.110 on Linux.

kav2k commented 8 years ago

Seems to be a case of #1 and is caused by a yet-unknown userscript. Can you list the userscripts you use for FL?

matthew-cline commented 8 years ago

Tampemonkey is installed but disabled, so I have no userscripts for FL. Also installed-but-disabled is the Fallen London Item Equiper.

Extensions which are operating on FL:

1 Click Translator
Middle Button New Tab
Stylish
Tabs to the front!
URL rewrite
Vimium

kav2k commented 8 years ago

What's running in Stylish then? Also, could you check the FL page's console for errors?

matthew-cline commented 8 years ago

Stylish has two rules for FL: one to change the cursor property, and one to change the text-decoration property.

Also, I can't reproduce the bug at-will, as logging out and then immediately back in doesn't demonstrate the bug; it only seems to happen if I get logged out for having been away from the site for a while.

matthew-cline commented 8 years ago

1) This bug seems to be intermittent. Over the past two loggins-after-timeout, the extension was working from the start.

2) In the instance where it didn't work from the start, I opened the Javascript console after logging in a saw no errors. Next time I'll have the console open before logging in.

matthew-cline commented 8 years ago

I had the console open before logging in, yet it still showed nothing unusual.

matthew-cline commented 8 years ago

I just moved my Chrome profile to a new computer with the same OS (Fedora 23) but a faster CPU, and now the bug has gone away.

kav2k commented 7 years ago

Reproduced, found a workaround. Fix forthcoming. Reason is a fascinating bug in Chrome.

matthew-cline commented 7 years ago

Reason is a fascinating bug in Chrome.

Do tell.

kav2k commented 7 years ago

@matthew-cline Sure, if you wish (but dibs on reporting that to Chrome bugtracker!)

Chrome content scripts (the part that interacts with webpages) have a run_at parameter, that designates when they are executed during page load. It defaults to "document_idle", which is the earliest of (200ms since DOMContentLoaded fired, window.load fired).

Under circumstances I didn't have the opportunity to properly isolate yet (but I suspect it has to do with a series of redirects after logging in and timing), "document_idle" is never reached for the FL main page. This means both declared and explicitly injected content scripts that do not specify a different run_at are stalled, waiting for the condition, never executing.

The fix in this case is to use run_at: "document_end" instead; it doesn't affect how the script runs, though it might slow down the page loading a fraction of a second. This phase does seem to trigger correctly in FL's case.

kav2k commented 7 years ago

Closed with 6310183844ca72d9a3d808a96b4fbee75af724bb

Release pending some more feature work