Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upAdd view-source protocol #4181
Add view-source protocol #4181
Comments
|
If this isn't taken already, can I work on this? |
|
Sure! |
|
I have some changes, but don't know how to test them. Do I just call |
|
I think so? You may need to modify the URL that gets passed to the HTTP loader, but I'm not certain. |
|
|
|
I don't have the time to work on this now, sorry. |
|
Is anyone working on this? If not, I'd be keen to try. |
|
You're welcome to it! |
This follows the recommendation from issue servo#4181. A handler for 'view-source' delegates to the HTTP loader. In that loader I check for view-source, adjust the URL to be the URL to be viewed and modify the Content-Type header to be text/plain. This doesn't actually result in the source being viewed as rendering text/plain is not yet implemented.
|
I've implemented the suggested approach of having a view-source handler, and modifying the content type to be text/plain if that is used. It's in doublec/servo@a788bcc. The content doesn't render as text/plain though as, I assume from issue #3649, it is not treated specially for rendering. Requesting text/plain content formats it as HTML. Should I pull request this as is? Or look at implementing text/plain beforehand? |
|
If you're willing, implementing text/plain would be great! That check probably belongs in ScriptTask::load for now. |
|
No worries, I'll get on to text/plain support! |
|
Is there a spec or a pointer to the way Gecko does text/plain display? Taking your ScriptTask pointer I hacked in a simple "wrap the text in a pre element with '<' escaped" to get something working. This lets me at test that the view-source changes I made work. I've put that in doublec/servo@d953dad. The following works: For a better text/plain solution would it be better to build the document up manually in ScriptTask::load instead of parse_html? And is the "put it in a pre" approach ok, or is there a better way of building up the document for plain text? |
|
Dealing with In particular, the HTML tokenizer has a |
|
Aha, thanks, that clears things up. |
This follows the recommendation from issue servo#4181. A handler for 'view-source' delegates to the HTTP loader. In that loader I check for view-source, adjust the URL to be the URL to be viewed and modify the Content-Type header to be text/plain. This doesn't actually result in the source being viewed as rendering text/plain is not yet implemented.
…xt, r=jdm
Implements view-source protocol by having a view-source handler, and modifying the content type to be text/plain if that is used.
Implements text/plain handling. This allows view-source content to display as plain text.
Example usage:
./mach run http://cd.pn/x.txt
./mach run view-source:http://tinyvid.tv/
This fixes issue #4181. Issue #3649 includes "support text/plain" so this possibly fixes some of that issue as well.
…xt, r=jdm
Implements view-source protocol by having a view-source handler, and modifying the content type to be text/plain if that is used.
Implements text/plain handling. This allows view-source content to display as plain text.
Example usage:
./mach run http://cd.pn/x.txt
./mach run view-source:http://tinyvid.tv/
This fixes issue #4181. Issue #3649 includes "support text/plain" so this possibly fixes some of that issue as well.
…xt, r=jdm
Implements view-source protocol by having a view-source handler, and modifying the content type to be text/plain if that is used.
Implements text/plain handling. This allows view-source content to display as plain text.
Example usage:
./mach run http://cd.pn/x.txt
./mach run view-source:http://tinyvid.tv/
This fixes issue #4181. Issue #3649 includes "support text/plain" so this possibly fixes some of that issue as well.
Make a handler that delegates to the HTTP loader then sets the Content-Type header to text/plain!