Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Firefox incorrectly disallows modification of page body by extensions on Wikipedia's File: pages

more options

I use the Dark Reader extension, which automatically modifies the style of any page to make it easier on the eyes. Like any extension that modifies the page body (as far as I know), it cannot modify certain pages and sites, such as https://addons.mozilla.org. For obvious reasons, it can also not modify PDFs opened in Firefox' built-in viewer. However, Firefox seems to always disallow modification if the URL ends in .pdf, regardless of whether that page actually is a PDF file. This becomes a problem on Wikipedia, where File: page URLs always end in their respective file extension, although they are completely regular HTML pages (example). This makes it so that you get effectively flashbanged every time you view that kind of page.

I assume this would also happen on sites with URL naming schemes similar to Wikipedia's, but I can't think of any to try and test it.

On an only marginally related note, because official Mozilla pages are also protected from page body modification, writing this post wasn't exactly pleasant either.

I use the [https://addons.mozilla.org/en-US/firefox/addon/darkreader/ Dark Reader] extension, which automatically modifies the style of any page to make it easier on the eyes. Like any extension that modifies the page body (as far as I know), it cannot modify certain pages and sites, such as https://addons.mozilla.org. For obvious reasons, it can also not modify PDFs opened in Firefox' built-in viewer. However, Firefox seems to always disallow modification if the URL ends in ''.pdf'', regardless of whether that page actually is a PDF file. This becomes a problem on Wikipedia, where ''File:'' page URLs always end in their respective file extension, although they are completely regular HTML pages ([https://en.wikipedia.org/wiki/File:ExtIPA_chart_(2015).pdf example]). This makes it so that you get effectively flashbanged every time you view that kind of page. I assume this would also happen on sites with URL naming schemes similar to Wikipedia's, but I can't think of any to try and test it. On an only marginally related note, because official Mozilla pages are also protected from page body modification, writing this post wasn't exactly pleasant either.
Attached screenshots

Chosen solution

Rummskartoffel said

Unfortunately, that workaround doesn't seem to work for me and neither does appending '#'. I might just have to wait and see what the extension's devs say.

I say this about it. Oh appending ? or # wouldn't work, as we `substring` the string from 0 to the last index of `?`/`#` so it will just return the full URL if you append it.

Read this answer in context 👍 0

All Replies (6)

more options

This is an issue that you need to bring to the add-on developer's attention.

The developer has obviously put a filter in place to stop certain pages from being modified based on the URL path. This not a restriction that Firefox put in place.

An add-on cannot modify the internal PDF viewer, but that's not determined by the URL, it's determined by the actual page content.

I tested with a modified version of one of my add-ons and I had no issue making modifications to the page you linked as a sample through an add-on.

more options

The extension has this code in is background/index.js file:

    function isPDF(url) {
        if (url.includes('.pdf')) {
            if (url.includes('?')) {
                url = url.substring(0, url.lastIndexOf('?'));
            }
            if (url.includes('#')) {
                url = url.substring(0, url.lastIndexOf('#'));
            }
            if (url.endsWith('.pdf')) {
                for (let i = url.length; 0 < i; i--) {
                    if (url[i] === '=') {
                        return false;
                    }
                    else if (url[i] === '/') {
                        return true;
                    }
                }
            }
            else {
                return false;
            }
        }
        return false;
    }

Further down there is a section that suggests that you can allow .pdf files, so you can check that out.

  • if (isPDF(url) && userSettings.enableForPDF) {return userSettings.enableForPDF;}
    function isURLEnabled(url, userSettings, { isProtected, isInDarkList }) {
        if (isProtected) {
            return false;
        }
        if (isPDF(url) && userSettings.enableForPDF) {
            return userSettings.enableForPDF;
        }
        const isURLInUserList = isURLInList(url, userSettings.siteList);
        if (userSettings.applyToListedOnly) {
            return isURLInUserList;
        }
        const isURLInEnabledList = isURLInList(url, userSettings.siteListEnabled);
        if (isURLInEnabledList && isInDarkList) {
            return true;
        }
        return (!isInDarkList && !isURLInUserList);
    }
more options

Thanks for the replies! I was not able to find any settings pertaining to PDFs, unfortunately, so I am currently writing a GitHub issue for the extension. Should I mark this question as solved?

more options

You can possibly append a '?' as a workaround

more options

Unfortunately, that workaround doesn't seem to work for me and neither does appending '#'. I might just have to wait and see what the extension's devs say.

more options

Chosen Solution

Rummskartoffel said

Unfortunately, that workaround doesn't seem to work for me and neither does appending '#'. I might just have to wait and see what the extension's devs say.

I say this about it. Oh appending ? or # wouldn't work, as we `substring` the string from 0 to the last index of `?`/`#` so it will just return the full URL if you append it.