On Mon, Feb 02, 2009 at 09:42:20AM -0300, Jorge Arellano Cid wrote:
On Mon, Feb 02, 2009 at 01:45:43AM +0000, corvid wrote:
Johannes wrote:
On Sun, Feb 01, 2009 at 07:45:39PM +0100, Hofmann Johannes wrote:
On Sun, Feb 01, 2009 at 03:53:32PM +0000, corvid wrote:
Jorge wrote:
On Sun, Feb 01, 2009 at 02:24:30AM +0000, corvid wrote: > Michal wrote: > > Hi, > > > > I am affraid there ocurred regression in post-dillo-2.0 when compared to > > dillo-2.0. Look on the www.blisty.cz web page, on the top there's > > following sence (it's in Czech) > > > > "??t??te Britsk? listy speci?ln?? upraven? pro va??e mobiln? telefony a PDA" > > > > but in current hg tip it's displayed as > > > > "???t???te Britsk??? listy speci???ln??? upraven??? pro va???e mobiln??? telefony a PDA" > > > > and of course, the whole page is displayed like in ISO-8859-1 coding. > > > > I noticed this first when the character coding code in post-dillo-2.0 > > was changed. > > > > When the page is saved to disk and opened it works as expected. > > > > It appeared that it is somehow related to default dillorc. > > > > 1) remove the ~/.dillo directory > > 2) dillo www.blisty.cz > > 3) --> PASS > > 4) quit dillo > > 5) dillo www.blisty.cz > > 6) --> FAIL > > > > Can anyone, please, have a look at this and say whether is it > > reproducible and, perhaps, fix it? :) > > Breaks for me, too. > > Plus having to wait through 116K of download before anything > appears is no fun.
It works for me! :-)
Seriously, I still have a pending item to review here, and it's when charset appears after the stylesheet in HEAD. This page also has timing issues: http://www.daemonnews.org
It looks like queueing the stylesheets and asking for them after charset or at head close may fix it.
Does anyone else experience pages not rendering until download is complete? I see this with the dillo.org pages, for instance, since the meta charset is iso-8859-1.
Yes, I'm also seeing it. Not sure when this started.
According to hg bisect it starts with d29cdb5b842e, but I don't see any obvious issues there. Jorge, can you have a look please?
With html->stop_parser = true; /* Avoid a race condition */ in Html_tag_open_meta(), we don't get to Html_tag_close_head in the usual way. We have to wait until the cache client callback is called with CA_Close, triggering DilloHtml::finishParsing, which closes all of the open tags. Html_tag_close_head() is called and we finally get our repush().
Good analysis.
I'm looking into both issues...
OK, the tip has a patch for both problems. It passes these tests: Feb03 load Reload Back ---------------------------- H__ OK OK OK H = has charset in HTTP header HM_ OK OK OK M = has charset in META H_S OK OK OK S = has remote CSS stylesheet HMS OK OK OK _ = disabled ___ OK OK OK _M_ OK OK OK __S OK OK OK t = timing issue _MS OK OK OK x = always fails ---------------------------- and the reported cases too. I still don't feel comfortable with this part of the code: it's complex and has the Cache_ref() trick. Anyway, as far as tests are concerned it behaves well. Please test and report. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________