Yeah, this is very annoying. I am kind of used to it since i’ve seen it on other forums, but it always makes me wonder - are our modern devices with all the gigabytes of memory and multi-core CPU-s (yes, even phones) really incapable of loading and displaying few MB of text? Or how much would something like 1000 posts/page be? Probably even less…
Will check it out.
BTW any luck getting the multi quoting issue addressed, i don’t always remember to type some dummy letters after a first quote so i can go back and make other quotes.
That makes sense but then it actually supports having pages.
But since i can do it in the forum but not in Firefox its strange there is a difference/problem.
I know some forums have gotten around the page issue glitch i mentioned by linking to the post not page/post. But then again thats presumably on the Discourse programmers side and not yours.
Hmm first time I’ve heard of the issue. I just tried it and everything seemed normal.
I had made a thread about it and this post mentioned the workaround
Ah yes, but I thought that was just a matter of not minimizing the post editor since the it allows for viewing/scrolling the thread simultaneously while the editor is open. Or is there a specific reason for minimizing the editor?
So that i can write posts full screen instead of split screen.
I often tend to be verbose and need the extra real estate without having to resize the edit window every time i use it.
I see, thanks. Sorry I didn’t report that issue because I assumed it was just a usability thing, but yours sounds like a valid usage case.
So I understand that you start with a blank reply, quote something, minimize the editor, select and quote something else, maximize the editor, and the first quote is gone?
Yeah it goes all wonky with that reload/ignore error
1 Thank
Never underestimate a web browser’s ability to use all available resources. 
But seriously, getting an accurate scrollbar involves a few things:
- Fetch all posts in the thread. This sends a whole bunch of requests to the server, increasing load and hosting costs.
- Render each post, to find out how much visual space it takes. This may result in an extremely large page canvas, like 1920 pixels wide by a million pixels tall. For a thread with 1000 posts, that could easily exceed the browser’s maximum memory limit per process. For a 10,000 post mega-thread, the canvas alone could exceed the total RAM on the entire computer.
- Once the above is done, an accurate scrollbar can be presented.
Even on old BLF, with just 30 posts per page, sometimes the canvas would exceed the limit the browser used for some functions. Like, there was a full-page screenshot tool, but the browser wouldn’t allow it to save images larger than 32768 pixels tall. And some pages, at 30 posts per page, exceeded that limit.
If accuracy isn’t as strict though, more efficient solutions could be used. Like, fetch only a few posts, and estimate the size of everything else without loading or rendering anything. Not sure how feasible this is, but it could theoretically work. That’s what Discourse’s timeline slider does, but I don’t know if it can be implemented at a browser level.
Or, if the goal is to reach the first or last post quickly, there are other, much simpler solutions:
- Press the Home or End key. Discourse uses these to jump to the first or last post.
- Click the begin or end date in the timeline widget. This works on mobile, where there are no keys to press.
These work pretty well. It’s like clicking the “first page” or “last page” buttons on the old site, except now there’s a hotkey for it.
1 Thank
I don’t tend to use them much and since other forums have pages and they don’t infinite scroll. As much as i started computing old school this is a situation where use the mouse.
Its not often i need to go to the first post, often i want to go up enough to read something or find a post i am planning to reply to.
That said i am open to trying the new format as long as its not glitchy. But it is.
I think they should fix the problem, i bet Firefox would be willing to make it a feature update if absolutely necessary, i have conversed with people who deal with bugs a long time ago, they are a decent bunch. It can even be a feature to help differentiate Firefox form its competitors.
I visit non forum websites that load more when the scroll-bar goes above or below whats already loaded, it still works even if the bar jumps while you are holding it with the mouse (i forget the name of it).
I think this forum is excellent personally.
2 Thanks
Home and End do this on almost every site. It’s the default behavior, unless the site overrides it. Home goes to the beginning, End goes to the end. Discourse supports this standard convention.
The browser’s scrollbar can’t show progress through the entire thread though, because that scrollbar has a different function which the page can’t override. It is outside the page, outside the viewport, and shows the viewport’s position within the currently-loaded canvas area. So Discourse renders its own pseudo-scrollbar inside the canvas, to add functions the browser-level scrollbar can’t provide.
1 Thank
I was wondering why you edited an older post to make it a reply to a newer post. This seems to make some odd things happen. Like, on my previous comment, in desktop mode, click on the " → Bort" thing at the top of the post, then click on the “1 Reply” button at the bottom… and it’ll expand both, showing the same post for each. The reply chain goes “A → B → A” and forms a loop.
Was that your way of cleverly showing a glitch? 
That kind of demonstrates why the Discourse folks can’t fix it, why they can’t make the browser scrollbar perform the same function as the thread timeline. It’s not within their power, because there is no code they could put into Discourse to make it happen. Instead, they would have to modify the browser.
… and modifying one browser wouldn’t really fix the problem, since people use many different browsers. They would have to modify every browser people use to view Discourse forums. Pretty huge task – current browsers already disagree about how scrollbars should work.
Standards and consistency among browsers have been a huge mess ever since the beginning of the web. Getting anything changed generally takes consensus among a consortium of leaders, plus decades of work. Like, they’ve been trying to address some shortcomings in CSS1 and CSS2 by making CSS3. That project began in 1998 and is still in progress. So the current version is CSS2.1. And what you’re proposing is more like a CSS4 feature. I’d be surprised to see it this decade, even if things went well.
If consensus was reached though, and they managed to get it widely implemented, it still wouldn’t fix the problem for anyone whose browser was compiled before the change landed. Discourse could either keep supporting today’s browsers, or drop support and break the site completely for a lot of people.
… and then there would probably be people complaining that the scrollbar is broken, and asking the Discourse devs to revert it back to the old “viewport position within canvas” behavior. Because the canvas scrollbar is useful, and going timeline-only would remove functionality.
I suppose they could serve both crowds by having two scrollbars though… and some sort of visual indicator about what each one does. Would that be an acceptable solution?
4 Thanks
I noticed that too, it was not intentional but i found it hard to explain.
Is that a bug?
I meant if its not fixable by Discourse.
As mentioned i have seen similar issues handled better.
That would be worse.
Pagination is probably the better way to go.
That said the software could have both, but thats above SB’s head.
It’s definitely a little odd, but it doesn’t appear to be a bug.
Not really sure what you mean. I just tried that here on BLF and it seems to work. Grab the scroll handle, go near the edge, and it loads more. It continues to work even if the handle jumps while it’s being held. At least, in a Chrome-based browser. I haven’t tried it on Firefox.
Two scrollbars is how it works now. One for the timeline, one for the canvas.
Pagination is conceptually almost the same thing, with one scrollbar for the timeline and one for the canvas. But the timeline scrollbar is a horizontal list of clickable numbers. And you have to explicitly click on the timeline to load posts outside the canvas, instead of just scrolling. And the hotkeys navigate the canvas instead of the timeline, so Home and End go to “current post number +/- modulo page size” instead of “1st post or last post”.
There are some other differences too, but in abstract terms it’s mostly just whether the timeline is horizontal or vertical, and whether loading happens on click or scroll.
This forum works great for me on mobile and desktop. Not sure what all the complaining is about.
2 Thanks
I was pretty new member with the previous lay out, and i did like it so much… basically i didn’t follow the forum that much because of it !
But this one it’s way better and it works quite good one my Android phone , plus i know this one from another forum !
Probably simply some older members was way longer with the previous one… so probably was more difficult for them… !?
I’m like you in that sense, I tend to have old school preferences in technology and yet I’m primarily a mouse user for most things.
Sorry if I’ve missed something, what is the glitch related to jumping to the first or last post by clicking the first or last date/time in the time slider?
In general terms I totally understand complaints about pointless change in technology, especially deletion of useful features or “dumbification” of the UI just to make it look clean or trendy. But in this specific case of pagination within forum threads I think it’s important to ask what advantages or actual utility did thread pagination offer? I honestly can’t think of any. With any forum only a few short posts or a partial long post can fit onto the visible screen area, so some method of navigating and viewing the context is necessary. In some scenarios pagination actually significantly hindered that flow. Let’s say there were 30 posts per page:
- I would be reading along, sometimes moving back up one or two posts to re-read something, and then move on until reaching the 30th post, and then move on to the top of page 2… and now I have no more context to refer back to.
- With Discourse I just keep scrolling/reading down, and I always have access to the immediately previous context by scrolling back up just a little bit.
- As I get a few more pages deeper into the thread I might see a post that says “UserX’s solution worked for me” with no link, so I start going back up in the thread again to look for a post by UserX, I reach the top of this page of posts and nothing yet so I click < previous, which takes me to the top of the previous thread and I now have to scroll down to scan for UserX’s post whereas on the previous page I was scrolling up. Nothing found yet, so I hit < previous again and I find UserX’s post in the middle of that page. Ok, but now I lost my place deeper into the thread before I went off on this tangent, so now I have to start clicking next > until I find where I left off.
- With Discourse, I simply scroll up until I find UserX’s post. When I’m done reading it, I hit the “Back” marker that takes me directly to the place where I left off:
- As I get toward the end of the long thread I want to refer back to a date range with some developments that I remember from a few weeks after the thread got started. I’m on page 177/179 , so I randomly decide to start looking somewhere around page 15. Except that the pagination controls are showing me:
« first|‹ previous|…|171|172|173|174|175|176|177|178|179|next ›|last »
So I click page First and then page 13 and then I finally see page 15 on the paginator to click it. (This is a real example taken from the old BLF in the Wayback Machine). Except that page isn’t even close to the date range I wanted, so I keep randomly jumping around in the paginator and/or manipulating the?page=Nvalue in the URL bar until I find the date range I wanted. The same process would apply if I wanted to jump to a specific post number or to the beginning of the second half of the thread.- With Discourse I drag the “timeline slider” until it shows the date range or specific post number that I want.
So there are some clear advantages to this particular Discourse innovation of the “timeline slider” and really no loss of functionality in this sense, aside from the loss of familiarity. As far as I can tell the forum pagination paradigm was necessitated by limitations in web technology before “AJAX” loading (loading new content onto the same canvas without clicking into a different URL / page) was invented. Since the entire long thread or long list of topics couldn’t be loaded into a single huge browser page, they had to split them up into pages with their own unique URL. But that doesn’t make it it a good solution in my opinion, apart from the fact that it’s familiar and is generally well accepted by users.
It’s also worth noting that scrollbars are being heavily de-emphasized at the OS level. Even most desktop OS environments are moving to skinny, low-contrast, disappearing scrollbars that only appear on mouseover, often with no stepper up/down controls. This is something that I vehemently detest, so much so that I do low-level modifications of my OS’s interface theming mechanisms (plural) to restore proper scrollbar functionality. But most users aren’t willing or able to do that. So it seems like a very pragmatic decision by the Discourse developers to have implemented their own scrollbar/timeline slider that is under their control. It even works well for mobile devices where the scrolling paradigm is both artificially neutered by trendy mobile OS designers as well as being inherently limited by the lack of precise mouse and keyboard input and reduced screen real estate.
2 Thanks
I was trying to answer that question in my head earlier, and I could only think of one thing: Paginated sites make it much easier to take a full-page screenshot. When the page is effectively infinite (or at least, bigger than the browser’s image limit of 32767 pixels tall), that type of screenshot doesn’t work. Gotta snap portions and stitch them manually instead.
There was another thing, but it turned out to be a non-issue. Automatic archival of every page the browser loads is easier with paginated sites, and nearly impossible on infinite-scroll sites. However, Discourse actually fixes that, by updating the browser’s URL to match the current viewport position. This then triggers a bunch of other stuff, which can then run an archiver on the correct URL, which downloads Discourse’s “Web 1.0” fallback mode for those URLs. So even though it’s a problem on most dynamic-loaded sites, it works fine on Discourse.
No other issues have come to mind.
1 Thank