On Mon, May 26, 2008 at 07:31:14PM +0000, corvid wrote:
Jorge wrote:
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 I mean it finishes seeing the first head, enables view source, user views the source, and then the charset in the second head causes a repush. Is the parser avoiding that?
Yes, once you are IN_BODY, HEAD can't be re-opened, and META doesn't work outside HEAD.
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.
Ah, yes. Stupid corner cases!
:)
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.
Maybe adding a callback that stuffs in line numbers before going into the regular plain callback would work and be tiny. a_Capi_open_url(Web, our_special_callback, ...) Oh well, I realize it's premature to dream too hard about this at this point :)
I'd prefer to try the dpi before optimizing. Having one path helps a lot with... Oh, I already gave that lines. ;) The ones that read the paper, please raise your hands. :-) -- Cheers Jorge.-