On Mon, May 26, 2008 at 03:01:53PM +0000, corvid wrote:
[...] - a_Cache_[gs]et_content_type and capi and nav. Ugh again. I don't know whether there's a timing issue with changing decoders due to a meta tag at the same time that a view source window is being opened.
Yes there is.
Simple to solve by allowing view source after parsing the HEAD element only.
Do you think badly-formed html with, e.g., <head>..</head><body>...</body><head><meta..charset..></head> <body>...</body> is worth worrying about?
This is already handled in the parser. But now that you mention this, we have to be careful with reload. It deletes the entry from the cache before making the request. A simple solution is just to close the view-source window in this corner case.
(Why content-type and not charset? I find switching to text/plain to use findtext on the source to be useful.)
Sorry, I don't understand the question.
I was saying that I was pushing around content-type instead of charset because I liked changing it to text/plain in the dialog. If there's no dialog, maybe I'll go back to charset.
"View source" as a bw is not a bad idea. It reuses code and adds findtext for free, but currently loses the line numbers. (which match nicely with the bug meter). This is a separate problem. One way to have both features in "View source" is with a dpi that gets the source from dillo and sends back an html page. The simple way is to prefix line numbers and wrap with PRE. It can be sent with a no-cache directive, or removed from cache upon window close. The problem of sending back and forth a huge page may be not as bad as it looks because huge pages are seldom inspected for source from a browser, and it can be handled anyway. -- Cheers Jorge.-