Allow arbitrary rules of all circumstances

[sjehuda]

The following set of rules won't have any effect on application/xml and text/xml because both are opened in browser.

The rules will work for application/atom+xml, application/rss+xml etc.

{
  "mime-mappings": {
    "application/atom+xml": "1text/plain",
    "application/rss+xml": "1text/plain",
    "application/rdf+xml": "1text/plain",
    "application/feed+json": "1text/plain",
    "application/x-atom+xml": "1text/plain",
    "application/x-rss+xml": "1text/plain",
    "application/x-rdf+xml": "1text/plain",
    "application/xml": "1text/plain",
    "text/xml": "1text/plain"
  },
  "sniffed-mime-mappings": {},
  "text-nosniff": false,
  "octet-sniff-mime": true,
  "override-download-type": false
}

Please allow setting arbitrary content-type, even to content-types that already are opened in browser.

I need this feature in order for my program to work. See https://github.com/greasemonkey/greasemonkey/issues/3164#issuecomment-1602216564

[Rob--W]

This is borderline out of scope for the extension. The purpose of the extension is to allow users to view content that can potentially be displayed inline but somehow is not. What you are effectively doing is to convert something that can already be displayed inline, to an alternative that does not correctly render the content.

Based on your comment + error message at https://github.com/greasemonkey/greasemonkey/issues/3164#issuecomment-1538367009, it looks like you are mainly looking for a work-around for your user script to work around the stricter parser requirements in XML documents. Instead of that, I suggest to convert your input to well-formed X(HT)ML (e.g. using the DOMParser API with type text/html) and then append the result (which should now be accepted by the document because serializing the result again produces well-formed markup).

For documentation on DOMParser, see https://developer.mozilla.org/en-US/docs/Web/API/DOMParser.

[sjehuda]

On Sun, 02 Jul 2023 07:35:47 -0700 Rob Wu @.***> wrote:

This is borderline out of scope for the extension. The purpose of the extension is to allow users to view content that can potentially be displayed inline but somehow is not. What you are effectively doing is to convert something that can already be displayed inline, to an alternative that does not correctly render the content.

Thank you for the elaborated answer.

Based on your comment + error message at https://github.com/greasemonkey/greasemonkey/issues/3164#issuecomment-1538367009, it looks like you are mainly looking for a work-around for your user script to work around the stricter parser requirements in XML documents. Instead of that, I suggest to convert your input to well-formed X(HT)ML (e.g. using the DOMParser API with type text/html) and then append the result (which should now be accepted by the document because serializing the result again produces well-formed markup).

That's correct.

I'm looking for a workaround, but not for the stricter parser requirements as it is now solved.

A more important issue is the lack of functionality, such as click(), which is resulted due to document.contentType being manifested as XML.

[sjehuda]

On Mon, 03 Jul 2023 03:49:41 -0700 Rob Wu @.***> wrote:

Closed #79 as not planned.

I agree.

After more thinking, it does seem unfit, yet not so to those who are willing manually edit plain text files, so it might still be a good addition.

I'have also referred to https://github.com/FirefoxBar/HeaderEditor/issues/252 in order to provide the experience that Open in Browser provides.

In any case, Open in Browser does allow my program to function in a reasonable manner, and is the only solution I have, currently.

Hence it is the only solution available in the program.

Open in Browser is a good idea and should be a built-in feature in all web browsers.