Instead of saving every page of a chapter in the browser history, it would be good to just save the link of one chapter to avoid "spamming that histor

[Eti2d]

Somehow (at least for Mac users), MD saves the links for every page of a chapter in the browser history which I find very annoying. E.g. if one chapter has 30 pages, 30 links will be saved in the browser history. This history obviously gets "spammed" a lot while reading mangas on this site. On other manga websites it's usually the case that only 1 link will be created per chapter, but not for every page.
It would be great if you could change that.

Additionally, it would be also very preferable not to load every page of a chapter separately, but the chapter as a whole. That would make it possible to quickly and fluently scroll down a chapter e.g. to the last page. Currently, I have to wait a bit to do it which is especially annoying when a chapter has way more than 20 pages because MD unfortunately only allows to load 20 pages beforehand. Therefore, changing this to whole chapters would be also great.
This is just my assumption, but I think the mentioned issues are also the reason why MD is more "Internet-consuming" than many other manga sites.

Best regards,
Eti2d

 

[MrIncognito]

@Eti2d
I think many sites have only one entry because either they're not actually properly tracking what page your on (and if you accidentally tap the back button or click a link you didn't mean to, haha nuts to you) or are using methods of tracking chapter progress that are unrealistic for MangaDex. A modern way of handling it would be using history.replaceState(), but that should definitely be an option if implemented, since many people may be used to the back button taking you back a page instead of out of the chapter entirely.

As for the second suggestion, there is a "preload all pages" button, but it does not and will not do that automatically for the very reason you mentioned: server load

 

[Eti2d]

Is it actually faithfully doing the job of going back to the page you've read until you've e.g. tapped the back button? In my experience, there certainly are cases in which I go back to the last page of a chapter after I've tapped the back button. But in most cases, it just goes back to the first page (but with the whole chapter loaded).
Is that only a browser-specific difference? (I'm currently using Safari on a Mac)

 

[BzzBzz]

Any site can't manage browser history because it's browser feature (what a surprise!)

Other sites "create" one link only because they use some methods to swap images on the same page. MD uses separate html pages for every manga page. Nothing to do here until Tea rewrite reader again 😎

Use private window or turn on "clear history when browser closed" - problem solved.

 

[MrIncognito]

@BzzBzz
If each page is a separate HTML page for you, it's because you're using the legacy reader. The current reader could implement such a feature.

Also, stop using the legacy reader.

 

[BzzBzz]

If each page is a separate HTML page for you, it's because you're using the legacy reader. The current reader could implement such a feature.

Also, stop using the legacy reader.

No wisdom like silence... (c)

 

[MrIncognito]

@AbyssalMonkey
Pages can dynamically change the URL at will without actually loading a new page. It's part of the history API.

 

[Holo]

@Teasday did it this way on purpose. I think there was a debate a long time ago about this.

 

[Assasinart]

it should also be mentioned that a lot of other sites do not allow you to save images and they compress and reduce the resolution size. MD allows you full access to each image. Also, when you swap out an image without changing pages it involves more stuff to code. When those site use this method of displaying images they often disable the ability to right click so that the common person doesn't get to save the image. While a "container" like that provides several features and benefits i don't think any of those extras are of benefit to MD since they have always had a stance of giving the community access to content that has not been resized.

Given the other stuff they have worked on i can only imagine them thinking. "extra coding effort to achieve exact same result, don't need the extra features to secure the images" not worth it.

Naturally a result of that is that each page gets a link in your browser history. If my history is full of stuff and i'm looking for something its usually pretty quick to scroll down it (continuous scrolling, google chrome). Or if i know what i'm looking for or the site it came from i use the search bar in my history.

 

[Teasday]

@Eti2d Page turns being added as new history items is very much deliberate and it works exactly how I wanted it, although I disabled the feature on long strip because it didn't make as much sense (so it just uses replaceState to update the address bar). I'm not planning on changing the functionality, but this is one of those things where I suppose I could add a setting for. Eventually.

Page loading is deliberately done sequentially and with a max limit, because the presumption is that people read their chapters in order from the first page to the last. Starting to load all pages at once won't make your first page load faster, especially if it's a chapter with dozens, if not over a hundred pages. And yes, it's to mitigate server load.

_{@AbyssalMonkey posted:}
The current reader also uses individual html for every page too.

Not sure what you mean here, the reader works dynamically instead of reloading the page.

 

[Eti2d]

@Teasday Thank you for the answer! A setting that would make us decide whether to add a new history item for every page or chapter would be very nice.
But did I understand you correctly that you disabled the feature (which adds a new history item for every page) in the long strip mode?
If that's the case, then it's a bit strange because that feature also happens in the long strip mode (at least on Safari and Chrome).

 

[Teasday]

_{@Eti2d posted:}

Thank you for the answer! A setting that would make us decide whether to add a new history item for every page or chapter would be very nice.
But did I understand you correctly that you disabled the feature (which adds a new history item for every page) in the long strip mode?
If that's the case, then it's a bit strange because that feature also happens in the long strip mode (at least on Safari and Chrome).

I'm definitely not seeing it happen on desktop Chrome. Like I said, long strip uses replaceState so the url does update depending on which page you've scrolled to, but it shouldn't be adding new history items per each page. It should when changing chapters though, that I don't see a reason to even make a setting for.

_{@AbyssalMonkey posted:}

I was stating that every page has its own URL. Html was the wrong word to use.

"Wrong word" is a bit of an understatement lol

 

[Eti2d]

@Teasday
Could it be that it's different for macOS-, iOS- and iPadOS-users?
I've used the long strip mode on Safari and Google Chrome with my Macbook Pro. To check if it's different on my iPhone or iPad, I've also used that mode on these devices (but in these 2 only on Safari). But in all 3 devices, the URL doesn't get updated after scrolling through each page but rather adds another one in my history. And to clarify, it's not after each chapter but after every single page of a chapter, I've scrolled over.
It might also be worth mentioning that all operating systems mentioned above have the latest version installed on my devices.

I've also noticed that while the URL really is different for each page (it has the page number at the end), it doesn't "jump" to the associated page when opening it, but, starting from page 1, loads all the pages according to the settings (e.g. 20 pages). I think that's because of the long strip mode I've put as default.

Are you aware of that?

 

[Teasday]

@Eti2d I'm not surprised at all if things don't work as they should on Safari, it's buggy as hell to the point I'd rather have to work with Internet Explorer 11. I knew about the history push limits they set but what you're describing is more like Safari is just using replaceState as pushState which makes absolutely no sense to me. Long strip is definitely not using pushState at all.

The reader should indeed begin loading images from the page in the url on long strip, and then start preloading the preceding pages. It was something I added a few months ago.

I dunno, I guess I would have to ask around and see if this can be confirmed. I have no idea how I would begin to fix it if this is actually the case, it's not worth removing the feature just because it doesn't work properly on one of the worst browsers.

 

[BzzBzz]

> BzzBzz created some confusion in the terms.

I didn't actually. Just because it doesn't have .html extension or dynamically generated instead of static or havily uses scripts doesn't mean it's not html. Open page source and first thing you will see is <!DOCTYPE html> 😇

Edit: just DL'ed some pages with wget and it's indeed different pages. Just 3 strings but still.

 

[Eti2d]

@Teasday
I don't know the view of a web-developer, but at least for Apple devices Safari is definitely the preferred browser to use and I don't have anything negative to say except that there might be a few problems in streaming videos on certain websites. This is actually why I also sometimes use Chrome (but only in these cases). Furthermore, it's actually a first that I've heard Safari belongs to one of the worst browsers. From what I've heard and read it actually seems to be the opposite which also aligns with my experience using this browser.
But regardless of whether Safari is good or bad, I do think that you shouldn't just neglect this browser as it's (probably by far) the number 1 browser used on all Apple devices (so including iPhone).

And as I've said before, the problem of replaceState doesn't seem to be only a problem specifically on Safari. It also happens on Google Chrome which is why I assume that it's the operating systems of the Apple devices that cause this problem. It would be good if you could check that.
As I'm no developer of this site myself (or a developer in general), I can only hope that this issue will be fixed one day.

 

[Teasday]

@Eti2d Safari annoys me because of how often it's that one browser where some js feature or CSS rule or whatever just doesn't work like it does on every other browser. I don't particularly care about its user interface or anything, as a web developer I care about not having a spend time fixing bugs that only happen on iOS devices.

Speaking of which, the reason it's a problem with the operating system is because all browsers on iOS devices are forced to use the same core as Safari instead of being allowed to use their own, so they're all essentially glorified Safari skins. So yeah, the same fundamental problems are going to occur on all of them, that's expected.

So when iOS bugs do pop up, it's less because I'm neglecting iOS browsers (as much as I would love to, mobile traffic on mangadex is huge) and more that I don't have an iPhone myself so I don't really test for it.

 

[MrIncognito]

> BzzBzz created some confusion in the terms.

I didn't actually. Just because it doesn't have .html extension or dynamically generated instead of static or havily uses scripts doesn't mean it's not html. Open page source and first thing you will see is <!DOCTYPE html> 😇

Edit: just DL'ed some pages with wget and it's indeed different pages. Just 3 strings but still.

One thing you 100% did and are continuing to do is confuse and mislead people into thinking something that isn't true, that is, that every time you click to go to the next page in the reader, it downloads an entirely new HTML from the server (it does not do this)

@Teasday

So when iOS bugs do pop up, it's less because I'm neglecting iOS browsers (as much as I would love to, mobile traffic on mangadex is huge) and more that I don't have an iPhone myself so I don't really test for it.

Even if you did have an iPhone or iPad, in order to use any sort of developer tools you'd also have to have a Mac, which is absolutely wonderful

 

[Teasday]

Yeah needing a Mac doesn't help.

And yes, the reader indeed does start with some html, being a page on the internet. What happens afterwards however is the reader javascript manipulating the DOM by adding, editing and deleting nodes. Calling it "html" is understandable but technically misleading.

 

[Eti2d]

@Teasday Hm..., that really sounds very annoying. I knew that the browsers have strict requirements that they have to fulfill in order to (be allowed to) operate on Apple's operating systems.
But I didn't think that it would be followed by that many problems. It's nice to know the view of a web developer regarding these issues. Thanks for the insight!