Modern Vespa

Issues with PM's and Preview feature are occurring. (Big Boss is aware and working on it.)

Preview is now fixed. A dumb typo late in a long change process. The code had been tested repeatedly, but I made one last change that went untested.

Doh. Sorry about that.

Still not sure about how to reproduce the PM problem -- I've sent and received several and haven't hit an issue yet. Can someone who has seen it fill me in on steps to reproduce?

... click the PM button within my post.

You should get a white screen

Hah. Yep.

You know, I almost never use that button.

Okay, this ended up being a very, very subtle bug. And to be completely clear, I broke it and deserve full discredit for doing so.

The extenuating circumstances are that this specific case -- starting a new PM targeted at a specific user -- was a case that wasn't actually handled in the code previously. Which, up until yesterday, didn't exactly matter, even though it was technically broken. It worked in spite of itself.

But my changes yesterday made sure it was really broken. Ahem.

This is fixed now. Thanks for the tips.

I've been coding more-or-less nonstop since I got back from Porto at the beginning of the month. I've managed to improve a few things, break a few things, and make lots of changes that -- in the end -- don't actually amount to a tangible improvement in anything about the site except how I feel about the code.

The epiphany I had yesterday, as I continued to hack at the PM feature (and largely break things) was that I could spend the rest of my life trying to improve the code, making piecemeal changes to straighten it out and make it saner. But to what end? The code might get better, but it doesn't materially change the user experience for all of you.

And I've actually been putting some pieces in place over the last year or so, bits of infrastructure to build a better, more modern site. There are a few pages using the new infrastructure, but none of the major pages that get loaded thousands of times a day.

I think the thing to do, then, is to stop straightening code and start rewriting entire parts of the website. Straightening the code isn't going to get me any closer to any of the goals that I have in mind. Rewriting big portions will at least advance the cause somewhat.

And so, I come to the point of this post. I have to make some decisions about the future infrastructure that could have a negative impact on some members. One of those decisions concerns the way we use javascript. Currently, we rely heavily on a library called jQuery, which is large-ish and also largely obsolete, as native javascript APIs have come along to fill in the gaps that jQuery once provided.

The decision hinges, as it often does, on browser support. One of the modern interfaces I would like to use to replace jQuery (one small piece of it, anyway) is called the Fetch API. It is widely supported by modern browsers, going back to about 2016. Notably, all versions of Internet Explorer do not support the Fetch API, and I know that some people (and even at least one moderator) might be negatively impacted if we switch away from jQuery and on to Fetch.

Or not. Maybe I'm trying too hard to support what at this point is ancient history.

Opinions welcome.

I say go for it. Especially if your new forum software is so bloody good you could even go so far as to license it out to others - but perhaps you'd prefer to just let it out into the wild anyway, as a public service.

Hah. There are far too many site-specific (and language-specific) decisions in my code for that.

If I was smart, I would have just converted to Discourse by now.

I'm not smart.

If the browser doesn't support Fetch then it also is too old to be getting security updates. You'd be doing users a service by forcing them to update to a modern browser.

I get where you're coming from, and I don't disagree, exactly. But niche sites like MV have to be careful about losing their niche users.

Well I'm here, so there's that....

When does a niche become a rut?

When it becomes boring.

I feel very seen.

is this my punishment for breaking the preview and PM functions?

Is this how you game?

SteelBytes wrote:
If the browser doesn't support Fetch then it also is too old to be getting security updates. You'd be doing users a service by forcing them to update to a modern browser. Could you put a post with a link to a suitable browser for download. And maybe instructions on whats needed.

close, but more like this:

Back to the topic of the thread

Jess, on the notifications page the red line saying 'previous visit' doesn't work the same any more. The red bell does go back to non red after viewing the page but the line doesn't reset.

Did you tinker with this?


I'll explain better later as it's bed time here.

https://www.microsoft.com/en-us/edge/download?form=MA13FJ

Chromium based (de-facto standard), but without the Google crap...

I haven't tinkered with it, but I think it's likely that it works as designed but not as expected. The red line isn't the last time you looked at notifications -- it's the last time you were on the site before your session expired. This is the same time that is used to generate the New synthetic forum -- where the time is actually explicitly shown.

You can see this effect more clearly if you log out and then log back in -- you'll see the line in Notifications move to the top.

weird. my brain must be borken as I could have sworn otherwise.

The red line can seem to behave as you probably expected. But that's because new notifications and a new session often coincide. Once you see that pattern a few times -- even though it is an accidental correlation -- it's easy to draw the wrong conclusions about what is actually happening.

I tend to have long-running sessions (many hours) while I'm working on the site, and browsing and posting in between coding tasks. When your session doesn't expire as often, new notifications come in while your session is still active. At that point, you see the real behavior more clearly.

When refreshing the page, whether to a different topic or just refreshing the current page, the page 'blinks' with just the background in view for a fraction of a second. This is quite distracting, and I'm fairly positive either didn't happen before the last few days, or happened so quickly it wasn't noticed. Doesn't seem to happen on the main index page though.

It would appear that it only happens on multi-page topics.

Investigating.

Updating: I don't think it's multi-page topics, specifically (though I looked hard at the new-ish pagination code). Rather, I think it has to do with the length of the page. All the pages of a multi-page topic (save for the last one) will be at maximum length (roughly speaking) and so seem to be more prone to the blink effect. Pages with only a handful of topics -- or only a handful of topics on the last page -- seem not to blink very much, if at all.

Which puts this bug squarely in the quasi-bizarro land of "site/browser interaction", and there may not be a definitive answer to be had.

I'm still looking, though.

Update 2: I can see the problem happening even with short pages on FireFox. Also, I can see it on utility pages that aren't part of the regular forum rendering, so I'm probably chasing my tail looking at recent code changes.

This is starting to feel unsolvable.

So after quite a bit of head scratching, research, and speculation (not necessarily in that order) I have concluded that there are probably a lot of different cases where you might see something that could be described as above -- I'd honestly need to either see your computer in action or have a very clear description of the problem with specific actions (i.e. from this page to this page, etc).

What I am seeing as a "blink" might not be the same thing you are seeing, or under the same conditions.

That said, there are two notable candidates.

The first one (and something that I did change recently) is that there are a few more cases where an intermediate redirect happens on the way to loading a page. The most common of these redirects will be after clicking on the left delta to jump to unread content, or clicking the right-hand arrow for the last post in a topic.

There shouldn't be a redirect when clicking on the title of the topic (from the list of topics) nor is there any redirect when reloading the page.

The second variation can be seen most easily when reloading a page, and (for me) usually manifests itself as everything from the first post down (not including the masthead at the top) either being absent then appearing or appearing momentarily shifted to the right before it goes back to the expected spot on the page.

I believe that this variant of "blink" was caused by the localized dates, which were initially encoded on the page in their standard UTC form, like so: Javascript then comes along and changes that to the properly localized date and time according to your user preferences (and also the whims of your browser).

The problem with that system is just that the UTC string is overly long, and it overflows the Author layout (when using the desktop view) on topics, specifically the date that the author joined the forum. Thus, the shift of the page to the right, as every author column on an entire topic must expand to hold the initial UTC string. Then when javascript comes along, the date would actually fit again, and the page would shift back to the left.

This problem seemed to be more noticeable on topics with more than a handful of posts on one page (i.e. every page of a multi-page topic except the last one). My theory is that on longer pages, the javascript wasn't firing until much later (the script include was at the end of the page) and so the chances were higher that a broken layout would be shown to the user before javascript corrected it.

I've fixed this in two ways. First, I am no longer putting a full UTC time and date into the initial placeholder text -- it wasn't necessary, and was only there as a failsafe if the javascript didn't run for some reason. Instead I just encode any yet-to-be-localized time and date as the text "UTC".

Second, I have moved the script include for the javascript that actually localizes the dates to the HTML header, with the defer keyword so that it doesn't block parsing of the rest of the page.

The result of that change is that you are likely to see the dates on the page flicker briefly (especially on longer pages) but you shouldn't see the actual layout change.

And if you have another variant of this problem and can tell me how to reproduce it, I'll be happy to take a look. Okay, not happy, exactly. But definitely interested.

Right now I think I can only see a very rapid 'blink' when refreshing the main index page - not a concern. The other very noticeable longer 'blink' has gone.

This change would appear to coincide with the change of background away from the Christmas scooters. Perhaps that was causing some page writing delay?

Windows 10, browser is Chrome, but with some ad-blockers and privacy gate-keepers.

I don't see any blink on the main index page at all, but could be a difference of browsers. I can see a blink -- on almost any page -- when reloading near the bottom of the page. But that's expected, as the lower parts of a page get updated last. Well that's a relief! It's always possible, but I think it was coincidental. There was a genuine problem with the joined date pushing the page layout to the side, and then a layout invalidation (and re-layout) after javascript ran. I could see the events happening in the Safari browser debugger.

Looks like we're both seeing similar events (or lack of them), despite different OSs and browsers. Well done with the date thingy!

Forgot to mention, or actually forgot that I did it: While I was still trying to figure out what was wrong, I logged out (anonymous users currently get only a background color and no pattern) and was still able to reproduce the blink problem.

So now that I've remembered that bit, I think it's safe to rule out the Santa scooter background image as the cause.

That's a relief.

I've managed to switch over the forum index pages to the new pagination model, which means that we get all the same improvements I've already made to topics. The elusive promise of reusability in object oriented design has actually paid off for a change.

This means you can now click on the ellipsis between groups of pages and go to a point halfway between the two.

HOWEVER: The database struggles to produce forum index pages from years back. Please use the ellipsis (which will quickly take you to page 1041 on the first go) sparingly.

A technical side note: the forum has never supported actual page numbers for forum indexes before. It had always used the dreaded "start=xxx" parameter, and each page was worth 50 units of start. We now use proper page numbering (starting at 1) and the URL notation follows the same standard as topic URL notation, namely: Where the forum ID is 2 (General Discussion) and the page number is 5.

Becomes
[MVFR] POLL: What should Jess fix next? (Page 12)

Hah. Did not think of that case.

Derp.

I had a couple of different options for fixing this, one of which was to honor the #top and #bottom fragments. However, doing so broke a lot of other things (and other assumptions) and so in the end I opted to ignore non-numerical trailing url fragments.

Thus, Becomes

[MVFR] POLL: What should Jess fix next? (Page 12)

Which is:

And just to verify: Should still become:

[MVFR] POLL: What should Jess fix next? (Post 2656649)

Which is:

Oh, and thanks for the tip!

Appears as

https://www.test.com/
https://www.test.com/

I do understand it's incorrect use. I'm only reporting it because i saw someone else do this accidentally.

That's actually quite useful on occasion.