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*'],
      }],
    },
  }],
});