flattr
Normalize browser Reading Mode URLs
Many browsers have Reader/-ing Modes and they’re incredibly useful in fixing broken page designs and making texts readable. However, they also change the URL of the article to a point where the Flattr extension no longer recognizes them. Flattr should recognize and normalize reader mode URLs so that the original URL can be Flattr’ed.
Firefox (URLencoded property)
about:reader?url=http%3A%2F%2Fexample.com%2F
Chrome (URLencoded property; mobile only)
chrome-distiller://uuid/?url=http%3A%2F%2Fexample.com%2F
Microsoft Edge (extra protocol)
read:http://example.com/
Safari (replaces protocol)
safari-reader:example.com/
I agree that it makes sense to support reader mode so I quickly looked into it:
Firefox Firefox doesn't run our content script on about-pages which means that we can't detect interactions that occur on the web page. That means that we'd need to look into possible workarounds because at this point our algorithm needs this information to work properly.
In other words: Even if we were to recognize, acknowledge and normalize such URLs, it'd lead to a significantly smaller amount of flattrs that the extension would generate.
Chrome Mobile Chrome Mobile doesn't support extensions.
Others We can look into reader mode on Edge and Safari when we start supporting those browsers. Presumably, we'll face a similar issue as on Firefox.
I don’t believe Mozilla will allow extensions to inject anything on the about: URI scheme.
However, Firefox 58 introduced some new reader mode APIs including an event for when a tab enters reading mode. Could be used to enable a limited tracking mode for this type of tabs that uses the browser.idle() API combined with window.focused to detect user activity in reader mode. This is how most extensions track which tabs have focus/are active for this type of purpose. Maybe not as accurate as the Flattr method, but works for the PDF viewer, reader mode, and other places where extensions can’t inject scripts.
I don’t believe Mozilla will allow extensions to inject anything on the about: URI scheme.
Me neither but there may be some other way to allow for that. Note that while they rejected switching to a "read:" protocol in the context of this ticket, revisiting that idea could make sense for fixing this issue. I've added a link to this issue there for more context.
Could be used to enable a limited tracking mode for this type of tabs that uses the browser.idle() API combined with window.focused to detect user activity in reader mode.
I'm not worrying too much about detecting whether the tab is in reader mode. But yes, we'd probably end up with a limited variant of the algorithm for such tabs similar to how we currently create flattrs based on history items.