Project

General

Profile

Feature #70

Add facility to replace sites' original HTML with custom one

Added by koszko 4 months ago. Updated 3 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Start date:
08/02/2021
Due date:
% Done:

0%

Estimated time:

Description

So far we were focusing on writing custom javascript for files. However, we often end up implementing our own site interface, either bacause

  1. site's original interface is entirely constructed with proprietary javascript or
  2. site's original interface is so unsuitable (e.g. has non-working interactive elements we don't want to support) that it just has to be replaced, or
  3. accessibility/usability/KISS principle requires it, or
  4. because we just want to.

Currently existing fixes heavily use document.creteElement() and construct replacement interfaces in javascript. While this works, it is not as convenient, as it could be. In the future we should allow custom HTML document to be included in a fix and rendered instead of site's original one. We could make the original document available to injected scripts through some global variable (say, hachette_document_original) for the purpose of extracting the necessary data from there.


Related issues

Related to Haketilo - Feature #69: Facilitate bundling HTML/XML/JSON and other data with a fixNew08/02/2021

Actions

History

#1

Updated by koszko 4 months ago

  • Related to Feature #69: Facilitate bundling HTML/XML/JSON and other data with a fix added
#2

Updated by koszko 3 months ago

Together with this, we could allow scripts to access the original, raw HTML code of the page in question. I am mentioning this here as requested in #78

We are perfectly able to:

  1. Use webRequest to modify response headers to spoof and force a content type like "text/plain"
  2. Access the raw HTML code from content script
  3. Use document.write() to display what we actually want to be displayed

So we would display the Hachette-provided HTML file :)

Also available in: Atom PDF