New metablock @filetype

[sjehuda]

This is a request to add new API to GM.xmlHttpRequest, or to the core of the Greasemonkey extension, that can influence a change in document.contentType.

See #3164 (comment)

---

I have a feed reader userscript which partially fails when page content/mime type contains xml.

Further investigating and testing, namely with extensions like Open in Browser and Header Editor, the failures are a result of content-type being set to xml.

The errors are as follows: (line position may not be accurate due to recent update)

Uncaught DOMException: Failed to set the 'innerHTML' property on 'Element': The provided markup is invalid XML, and therefore cannot be inserted into an XML document.
    at infoSquare (userscript:org.openuserjs.sjehuda.newspaper/Newspaper:2195:17)
    at Element.<anonymous> (userscript:org.openuserjs.sjehuda.newspaper/Newspaper:2049:7)

Uncaught TypeError: Cannot set property 'display' of undefined
    at XMLDocument.<anonymous> (VM96 Newspaper:2127)

Attempts to forge response type either with Fetch or XHR have also failed.

Is there a solution or should a new metablock or API similar to webRequest.onHeadersReceived be added?

[arantius]

Getting the document again will never change the type that it was when it was loaded.

You'll need to be a lot more specific about specifically what you want, and how/why it would improve your use case.

[sjehuda]

Getting the document again will never change the type that it was when it was loaded.

Yes, so I've found out.

You'll need to be a lot more specific about specifically what you want, and how/why it would improve your use case.

I have wrote a userscript that converts structured data files (i.e. XML and JSON) into human readable HTML files.

Overhaul, the program works as expected; documents are processed and forged successfully into HTML.

The problem comes after the document is placed into viewport.

Using event listeners, the program offers extra functionality, mostly for accessibility, yet it also offers critical functionality such as Provident Image Load (aka "lazy" load) which is essential, due to bandwidth and hardware resources.

All the extra functionalities work well when document.contentType (read only) does not contain xml.

However, once document.contentType has xml, any code that contains querySelector would fail because the document is believed to be whatever document.contentType has determined upon initial request (an XML file), and, apparently, the web browser doesn't check document once it has been loaded.

An error message from the program suggests the file processed is XML when in reality it is an HTML, hence hinders other functions to be executed:

Uncaught DOMException: Failed to set the 'innerHTML' property on 'Element': The provided markup is invalid XML, and therefore cannot be inserted into an XML document.
    at infoSquare (userscript:org.openuserjs.sjehuda.newspaper/Newspaper:2287:17)
    at Element.<anonymous> (userscript:org.openuserjs.sjehuda.newspaper/Newspaper:2141:7)

Another related error:

Uncaught TypeError: Cannot set property 'display' of undefined
    at XMLDocument.<anonymous> (VM8 Newspaper:2374)

Attribute style can't be used with XML document.

[sjehuda]

I have added to Newspaper userscript an info message that is displayed at the top of a page when document.contentType includes xml.

Interestingly, when executing document.contentType from the userscript, the content type is correct text/html, yet we are here and the browser determination is a setback.

Test page (application/xml): https://lzone.de/liferea/blog/feed.xml

[sjehuda]

I think it would be most appropriate to incorporate the capability of the program Open in Browser into metablocks as follows:

// @filetype text/xml text/html
// @filetype application/xml text/html
// @filetype application/rss+xml text/html
// @filetype application/atom+xml text/html

@filetype: @mimetype would be good too
text/html: text/plain would be good too

[arantius]

Infeasible without significant refactoring (we don't know this information when we're running scripts https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webNavigation/onCommitted#details_2 ), the cost/benefit of potentially breaking existing scripts by changing how they run doesn't seem worth it.

[sjehuda]

I have managed to overcome this setback, namely by passing the HTML element newDocument and processing it in all ways feasible (see preProcess) and then replacing document by newDocument. See v24.04.06 vs. v24.04.08.

There was also another matter which required to create an element and change CSS Stylesheet in order to get the expected behaviour, because JavaScript attribute style does not work with document.contentType that ends with XML. See v24.04.08 vs. v24.04.09.

The only functionality which remains not to work upon XML is mode switcher (bright and dark) due to attribute style, yet it might be possible to fix.