BUG WATCH! - If you see a bug report it here!

[Dan Q]

Two suggestions:

Update advice on "surf no embed" page?

The Surf Navigator's "I can't embed this in a frame" page contains the following text:

If you are the site owner, you'll need to enable "X-Frame-Options: ALLOW-FROM" in your web server configuration to fix this error!

This is probably outdated advice. The ALLOW-FROM directive isn't supported by any modern browser except Firefox for Android. People should probably be pointed in the direction of Content-Security-Policy: frame-ancestors instead.

Update backend code detecting non-embedability?

Possibly the backend code is also looking for this header, too, in order to set up the allowsEmbed attribute in surfClubSites.json?

If both an X-Frame-Options: and a Content-Security-Policy: header are present, and the Content-Security-Policy: header contains a frame-ancestors directive, then the latter takes precedence!

For example, https://danq.me/ exposes the following headers:

Code

X-Frame-Options: SAMEORIGIN
Content-Security-Policy: [...] frame-ancestors 'self' https://melonland.net; [...] 

These headers say:

• If a browser understands only the X-Frame-Options: header, only allow danq.me to load danq.me in a frameset
• But if the browser understands the more-modern Content-Security-Policy:, also allow danq.me to be loaded in a frameset by melonland.net

That latter directive ought to make the surf navigator work. In fact, it does, if I manually hack the src of the <iframe> with my debugger (you can try this yourself by going to https://melonland.net/surf-navigator?site=3133 and repointing the <iframe> from small-pages/surf-no-embed.html to https://danq.me/ - it should work)! But I'm guessing that the backend code is seeing my "fallback" X-Frame-Options: SAMEORIGIN and disallowing it from being shown?

Hope that all makes sense. Sorry I keep making work for you!

[KiwiMeowo]

When I post a reply with a quote in a forum and get alerted by the "quote is too long" warning, I couldn't edit the message until I refresh or click preview.

[Dan Q]

Since the HTTP compatibility changes, the "click here" (to approve or deny their request) link when somebody sends you a buddy request is broken. It looks like the link was a scheme-neutral one (beginning //) but has accidentally been preprended with a scheme and domain, resulting in links that look like this:

Code

<a href="http:////forum.melonland.net///forum.melonland.net/index.php?action=profile;area=lists;sa=buddies;u=3133" class="bbc_link" target="_blank" rel="noopener noreferrer">Click here</a> to approve or deny their request.

Or else possibly a double-escaping issue.

[Melooon]

Since the HTTP compatibility changes, the "click here"

Possibly fixed! Thanks for reporting this one, I suspect there will be a few bugs like this - I think its because the PM you receive is going through normal text processing, but its using an internal server address, I suspect any server-sent-PM might have this issue, but buddies might be the only subsystem to do that?? Unless guilds do them too?

[larvapuppy]

@Melooon I can confirm that the guild requests do the same thing!