Incompatibility with Wikipedia, Wikisource & Wikimedia Commons page names

[pigsonthewing]

The add-on attempts to open pages such as:

• https://en.wikisource.org/wiki/Index:Notes_and_collections_relating_to_the_parish_of_Aldridge,_Part_2.djvu
• https://commons.wikimedia.org/wiki/File:Notes_and_collections_relating_to_the_parish_of_Aldridge,_Part_2.djvu
• https://en.wikipedia.org/wiki/File:Mozart_Sonate_(manuscript).djvu

(note that the "en.wikipedia" part of the latter URL includes an ISO 639 language code, "en", of which Wikipedia uses about 300 in URLs, and Wikisource a smaller number)

and rejects them as not valid DjVu files.

Each project has thousands of such pages/ files. All are are HTML pages about DjVu files.

The corresponding file for the first two examples is found at:

• https://upload.wikimedia.org/wikipedia/commons/a/ac/Notes_and_collections_relating_to_the_parish_of_Aldridge%2C_Part_2.djvu

and the latter is at:

• https://upload.wikimedia.org/wikipedia/commons/8/8f/Mozart_Sonate_%28manuscript%29.djvu

(where the "a/ac/" and "8/8f/" part of the URL is variable).

It would be good if the add-on could recognise the difference.

[pigsonthewing]

A simple test would be

IF domain = [wikisource.org OR wikipedia.org OR wikimedia.org] AND [URL includes "Index:" or "File:"] THEN treat as HTML

[RussCoder]

Thanks for reporting it.

Before Google forced all extensions to use the manifest v3, there used to be an option "Detect .djvu files via HTTP headers". This option is still present in Firefox, although it doesn't solve this problem, because it cannot be enabled separately. But it's very easy to make it separate there. So for Firefox it can be a solution.

As for Chrome, I need to think about it. You know, I dislike adding Wikipedia URLs to the code, I would like to find a more universal solution. And this redirection is not done dynamically via the code, the rule is declarative:

chrome.declarativeNetRequest.updateDynamicRules({
    removeRuleIds: [httpRedirectRuleId],
    addRules: [{
        id: httpRedirectRuleId,
        action: {
            type: 'redirect',
            redirect: { regexSubstitution: `${extensionUrl}?url=\\0` },
        },
        condition: {
            isUrlFilterCaseSensitive: false,
            regexFilter: '^https?://[^?]+\\.djvu?(\\?.*)?',
            resourceTypes: ['main_frame', 'sub_frame'],
        },
    }],
});

So to implement the test logic you suggested, I will have to edit the regex, and I would prefer not to do it.

With the manifest v3, it's impossible to analyze headers on the fly, but I need to check their docs once again - maybe they added some new APIs that will allow me to detect HTML pages whose URLs end with ".djvu".

[pigsonthewing]

Noted, thanks.

[shreevatsa]

I'm running into this issue too, and had to disable this extension on my browser temporarily. (Thank you for this extension!) Something like the following may work (based on some questions asking AI back and forth, and I've not tested it, sorry for the noise if this is incorrect):

chrome.declarativeNetRequest.updateDynamicRules({
  removeRuleIds: [httpRedirectRuleId],
  addRules: [{
    id: httpRedirectRuleId,
    priority: 1,
    action: {
      type: 'redirect',
      redirect: { regexSubstitution: `${extensionUrl}?url=\\0` },
    },
    condition: {
      isUrlFilterCaseSensitive: false,
      regexFilter: '^https?://[^?]+\\.djvu?(\\?.*)?',
      resourceTypes: ['main_frame', 'sub_frame'],

      // Chrome 128+: only match real DjVu responses
      responseHeaders: [{
        header: 'content-type',
        values: ['image/vnd.djvu*', 'image/x-djvu*'],
      }],

      // ...and explicitly ignore HTML wrapper pages
      excludedResponseHeaders: [{
        header: 'content-type',
        values: ['text/html*', 'application/xhtml+xml*'],
      }],
    },
  }],
});

[frankslin]

I've opened #105 for this. Since it does the Wikimedia-specific thing you were
hoping to avoid, let me explain the reasoning rather than just drop a diff.

Your reluctance to hard-code Wikimedia URLs into a general-purpose extension
makes complete sense, and I'd want a universal rule too. But I think the
Wikimedia case is worth fixing even with a non-universal fix. Wikimedia Commons
is in practice the largest public collection of DjVu files on the web, and
Wikisource's entire proofreading workflow (the Index: and Page: namespaces)
is built on top of DjVu and PDF scans. For a large share of the people who
install a DjVu extension at all, wiki pages are exactly where they encounter
DjVu files. Right now the extension makes those pages unreachable — you can't
even get as far as the "Original file" link that would hand you the real DjVu —
so it ends up blocking the very workflow it exists to serve. Having to disable
the extension, as @shreevatsa described, was my experience too.

So the PR has a deliberately modest goal: make MediaWiki URLs browsable again,
and give users a way out when the extension guesses wrong. It doesn't try to be
the universal solution you're after. Two things I tried to get right:

• The wiki knowledge is quarantined, not woven into your matching logic.
  Your redirect rule stays as it is; the Wikimedia part is a separate, higher
  priority allow rule sitting next to it. It's one rule you could delete in a
  single commit the day a better mechanism exists. requestDomains matches
  subdomains, so it covers all ~300 language codes without enumerating them,
  and files on upload.wikimedia.org are still intercepted exactly as before.

• The escape hatch isn't wiki-specific. Any URL carrying djvu-js=off is
  ignored by the interceptors, and the viewer offers a link with that marker
  when a document fails to load. So a page misdetected on any site is one
  click from opening normally, rather than a dead end.

As for responseHeaders / excludedResponseHeaders (Chrome 128+) that
@shreevatsa raised — that does look like the domain-agnostic condition you were
hoping for, and I'd be glad to look into it later if you're interested. I
didn't build on it here because the docs are ambiguous about whether a
redirect action still takes effect once a rule is deferred to the
headers-received stage: one passage says such a rule "cannot actually block or
redirect the request", another says Chrome "may block or redirect". That
deserves a proper experiment rather than being folded into a bug fix.

No hard feelings if you'd rather wait for that instead — the PR is there either
way.