SOUP causes Chat Easter Egg script to load twice in Edge

[gparyani]

When using this script along with SOUP in Microsoft Edge, the dropdown it adds to the page shows up twice (or used to until the author of that script added a workaround). Disabling SOUP fixes it.

I reported this to the developer of that script, who responded by implementing a workaround that explicitly prevents their script from loading twice and displays a console error message if it attempts to load twice. With SOUP disabled, I don't see this console message; with SOUP enabled, I do. This is still a bug, because the script shouldn't be attempting to load twice with SOUP enabled in the first place.

Also, according to that script's developer, the problem does not occur in Chrome, so it could be a bug in Edge or in the implementation of the Edge port of Tampermonkey. I reported this here to investigate if this is indeed a problem in SOUP or not, since disabling SOUP fixes the issue.

[vyznev]

Thanks for the report! Honestly, I have no idea what might be causing it, and I still don't have easy access to Edge to test it on.

If you'd like to help test this, one thing you could do is try to figure out which SOUP fix (if any) triggers it. If you open the SOUP code for editing in Tampermonkey, you'll see that most of it is made up of blocks of code like this:

fixes.site12345 = {
    title: 'Some title here',
    url: 'https://site.meta.stackexchange.com/q/12345',
    // ...
};

Each of those blocks contains a fix for a single issue (or, occasionally, a bunch of closely related ones), and they're designed to be self-contained enough that one can pretty safely just remove any such block without affecting the others.

So what you could do is just rip out a bunch of fixes from SOUP, save it, reload the page and check if the double loading message still comes up. Repeat until it doesn't, then undo the most recent removal and try removing something else.

Eventually, you should find one fix (or, just possibly, a couple of fixes interacting somehow) such that removing it stops the bug from happening, while removing all other fixes doesn't. Or, just possibly, it might turn out that the problem still persists after removing all the fixes from SOUP, which would also be an interesting result (since it would suggest that the trigger is in the shared helper/injection code at the end of SOUP, or possibly even in the user script headers).

Of course, I completely understand if you don't have the time or interest to do all that. But if you do, it could be helpful in tracking down the cause of this weird behavior.

[gparyani]

It's not that much of a problem now, because of the workaround the script author added. That said, I still think it should be investigated, as it's a bug.

I'm leaving this open in case someone else wants to investigate it, or if I have enough time later.

[BrockA]

@gparyani, you get a console error:

displays a console error message if it attempts to load twice.

What is the first word of that message? (Should be true or false).

---

Also, SOUP is set to @run-at document-start. If you use the Tampermonkey editor to remove that line (don't just comment it out), does the problem persist?

[gparyani]

@BrockA It's true.

I don't see document-start for run-at. I see document-body instead. Changing that line to document-start fixes the issue. Removing that line stops the script from executing.

[vyznev]

@gparyani SOUP does have @run-at document-start (and has had it since the earliest versions, since some of the fixes depend on it to work reliably; that's why this Tampermonkey bug is so annoying). I think you were editing the headers of the Easter egg script instead.

But it's interesting that making the Easter egg script run at document-start fixes the issue, although I'm not sure what to actually make of it. It could indeed point to a Tampermonkey/Edge bug with user script injection, or it could simply mean that the issue occurs only when SOUP runs before the Easter eggs script.

[vyznev]

One thing you could test is what happens if you remove all the code from SOUP (i.e. everything below the // ==/UserScript== line) and just leave the header. If it's a Tampermonkey bug, just having any user script with @run-at document-start (even one with no code whatsoever) might be enough to trigger it. On the other hand, if it's caused by some code in SOUP, then removing all the code certainly ought to make it stop happening.

[BrockA]

The true means it's likely not an iframe issue.

But the window load event is firing twice when 2 scripts have certain different @run-at settings on TM on Edge.

This strongly suggests that it is a TM on Edge bug. (More likely, TM has yet to work around an underlying Edge bug.)

[gparyani]

I'm not too technical with JavaScript, so @BrockA or @vyznev can one of you please report the bug to TM and see what they say?

[BrockA]

@gparyani, I can't. I don't have MS Edge and won't ever use it.

[derjanb]

@gparyani What is your MS Edge version?

But the window load event is firing twice when 2 scripts have certain different @run-at settings on TM on Edge.

@BrockA: I can neither reproduce this issue (of course after reverting the @noframes fix) nor trigger the issue that the load event is being fired twice. Do you have some more details on how to reproduce this?

Tested with MS Edge version:
Microsoft Edge 41.17025.1000.0 Microsoft EdgeHTML 16.17025 and
Microsoft Edge 42.17134.1.0 Microsoft EdgeHTML 17.17134

Thanks

[BrockA]

@derjanb , I don't think I ever saw the bug myself since I don't use MS Edge and don't support MS Edge. Was debugging remotely via website messages.
From the OP's reports and tests I had him run, it doesn't look like an iframes issue.

It looks like, @run-at document-start on one script, might be interfering with (or double-running) load time (or load event) of second script set explicitly to @run-at document-body -- but only on MS browser.

[gparyani]

@derjanb I'm running Edge 41.16299.371.0. (Based on your build numbers, I assume you're participating in the Windows Insider Program; I guess this issue will be fixed when I install the April 2018 Update, as I'm no longer a member of the Insider Program.)