Styles Only Apply on Reload

[MiniCoder11]

So, we are now facing quite a large issue. Tampermonkey only applies styles when the page is reloaded, this means that the styles that don't apply unless the project is loaded into the editor will never appear when you click the "See inside" button unless you reload the page in the editor.

How should we go about fixing this? We could manually attach a onclick="" event to the "See inside" button to reload the page?

Let me hear your thoughts.

Affected version(s): All

[VFDan]

That could be a good idea.

[VFDan]

Nothing I'm doing seems to be affecting the page at all. Could you give it a try? (Also it goes the other way too)

[MiniCoder11]

@VFDan The onclick="" method doesn't seem to be working. We may have to add in a MutatedObserver to detect whenever the URL changes.

[VFDan]

Please try that (also I tried checking if the dark theme was active; that did not work)

[MiniCoder11]

@VFDan Can we deploy first or is this issue to critical?

[VFDan]

@MiniCoder11 I think we should fix all the uncolored parts of the site first. I think once we resolve this and #8 we should be able to deploy.

[MiniCoder11]

@VFDan Could you make a separate issue with a list of uncolored areas and/or screenshots? It would make tweaking them a lot easier for me. I don't think I'll be able to change some of the buttons though, although a lot of buttons need their text color set to black.

[VFDan]

Sure, I'll make an issue (currently #8 encompassses all; if we need more, i'll make one)

[MiniCoder11]

@VFDan Good point, maybe just edit #8 for now with the list/screenshots of the places we’ll need to fix?

[MiniCoder11]

@VFDan Okay, so the onclick="" doesn't do anything when attached to the "See Inside" button because Scratch is using REACT for all mouse-handling. This means we are forced to do one of two things:

1. Use a loop that could potentially hamper the performance of the editor and player by several frames-per-second. This method is the easiest to implement but also has several major downsides. Most browsers also won't let us run loops like this and sustain them for very long.

2. Create a custom event listener that detects a change in the page URL. This works in most cases but won't work if the client is using HTTPS encrypted DNS. In that case, the project can't check for any part of the URL past the first "/" which means we can't tell if the user is in the editor or not.

Plan B: If all else fails, we should probably look for a third-party solution/library that can help us check when the page loads. Remember that although something works well on Tampermonkey, it may not work on other userscript platforms.

I know you're really busy right now so I'll wait for a response.

[VFDan]

Wait, I had an idea. Do the project page styles and editor styles conflict? If not, then we can just load both those styles for project pages and editor pages; this will also solve any problems in the reverse direction. (And thanks for your thoughtfulness!)

[MiniCoder11]

The styles do conflict in most cases because the editor uses an even darker theme than the rest of the site. That was one of the main reasons why we had to separate the styles in the first place. Any other ideas?

[VFDan]

That's not really what I asked; I meant like the classes in the editor, .editor-main (or whatever), are any of them used on the project page?

[MiniCoder11]

Some styles are used on the project page but the ones that are currently isolated to specific pages also conflict with an existing color. Even if we found a few universal styles, we wouldn’t be able to compete a working editor that looks any good (Many of the button styles have to be different in the editor than in the player for example). I understand what you’re saying, I’m just not sure I phrased my answer very well.

I had an idea yesterday... Is there any Tampermonkey metadata that forces the styles to reapply when the URL changes? Surely there must be.

[VFDan]

No, not that I can see in here. However, this might be useful (@grant GM_addStyle is necessary)

[MiniCoder11]

Good news! Someone appears to have solved our problem here: https://stackoverflow.com/questions. Should I go ahead and implement it?

[VFDan]

Yea, I think you should, but of course give credit to them :)

[MiniCoder11]

I’ve tried using the script they mentioned at the link I mentioned before but it appears to be obsolete or deprecated now and it doesn’t seem to work. The good news is that all the broken styles from are gone!

[MiniCoder11]

Solved in version 1.2.1! I also fixed a broken style before you caught it 😄. I think we're ready to deploy but you should test it out first to make sure it meets your standards.

[MiniCoder11]

@VFDan Also, I just saw the repository transfer and userscript organization invites (Google waited to deliver them to my desktop until yesterday). Sorry that I didn't accept them before. Now they've all expired 😄.

[VFDan]

It's fine, i'll send them again (also there'll be no organization). Thanks for your amazing work, as usual. :)

[MiniCoder11]

Actually, now I'm a little hesitant to accept the transfer as GitHub is warning me that we'll lose access to:

• Codeowners functionality.
  • Any existing wikis.
  • Pulse, Contributors, Community, Traffic, Commits, Code Frequency and Network on the Insights page.
  • Draft PRs
  • Multiple assignees for issues and PRs
  • Multiple PR reviewers
  • Branch protection rules.
  • Any existing Pages.

Should we be concerned about any of this? (The multiple assignees and branch protection are the ones that worry me the most).

[VFDan]

I also have Github Free, so I don't know why it is saying that...

[MiniCoder11]

Oh, okay. In that case, I guess I won't mess anything up by accepting.