sixcious / url-incrementer

Increment a URL or go to the next page. Supports auto, multi, and advanced incrementing functions.
Other
42 stars 3 forks source link

Not incrementing "Error: Frame with ID 0 is showing error page? #21

Open mcg772 opened 2 days ago

mcg772 commented 2 days ago

Description

Hello. You extension is amazing and I use it for various reasons, one of which is keeping up to date with memos from a law firm which are PDFs on a public website. But it's stopped working how it usually works. Your incrementer allows me to select part of the URL and then automatically increment it to scan through PDF files. If there is a PDF at the URL It opens it and I see the title and either pause to read the document or let it run and continue moving through the URLs until it reaches something I'm interested in.

Thing is, not every URL has a file at the end of it, in fact most of them don't (not sure why, assume it's the website system the firm uses).

E.g., Below is an actual working URL. https://www.wlrk.com/webdocs/wlrknew/ClientMemos/WLRK/WLRK.28510.24.pdf

In this case the number I am incrementing is '10' (in 28510), as in going from 10 to 11 and then to 12 and so on. image

But there is not always a file and if a dead page was reached the incrementer would keep moving along incrementing and when it reached a URL with a file I could pause and continue. Now, it stalls as soon as there is no valid page at the URL.

This is how I configure it: image

When the incrementer hits a URL that has no file (e.g. https://www.wlrk.com/webdocs/wlrknew/ClientMemos/WLRK/WLRK.28514.24.pdf) I get this error message. image

I can see from a couple of other posts that someone else has this or something similar.

I've removed the extension and added back but no luck.

Thank you.

URL

https://www.wlrk.com/webdocs/wlrknew/ClientMemos/WLRK/WLRK.28514.24.pdf

Version

6

Browser

Chrome 130.0.6723.92 (Official Build) (arm64)

OS

MacOS 15.1 (24B83)

Device

Other

sixcious commented 2 days ago

Hi mcg, thank you so much for the kind words and for opening this issue! ❤️

Yes, I'm aware of this one; this is basically Point 2 in #19, and is an edge-case that occurs on missing file error pages.

Here's what happened: Chrome removed persistent backgrounds in Manifest V3 (the latest spec for the platform), so I had to redesign URLI completely from the ground-up to no longer use the Background to perform actions. It now has to use the actual web page you are on to do all of that logic. However, when the web page is an error page, Chrome decided it won't let the app run on the page, so you're left with this situation. This is an edge-case I didn't catch before releasing it, since it literally only happens on protected browser pages and missing file pages, which is not the typical use-case.

It is possible for me to detect when this happens and I can try and fall back temporarily to using the Background, although it makes the code a lot more messier. I plan on releasing an update that addresses this; I was hoping for last month, but it is actually a lot more complex than I initially thought (especially in the case of AUTO, which you're also using, and goes down another rabbit hole), so I'm now shooting for November, or worst case, December.

I just want you to know though that it is your browser that is preventing URLI from working in this scenario, and not URLI itself.