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? :) Thanks, -- Regards, Michal Nowak
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.
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. I want to update the image process documentation before getting into this bug. If *somebody* wants to do it before me, go ahead! :-) -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
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.
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.
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? Cheers, Johannes
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().
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... -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
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 ______________________________________________________________________
Jorge wrote:
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.
I find myself thinking again how dicache for image/* with RGB internally is a lot like ??? for text/* with UTF-8 internally but they are handled completely differently. Of course I don't know dicache well enough to be too sure quite how far that analogy holds...
On Tue, Feb 03, 2009 at 09:34:17AM -0300, Jorge Arellano Cid wrote:
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.
Thanks, Jorge, I can confirm it's fixed now. -- Regards, Michal Nowak
participants (4)
-
corvid＠lavabit.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
newman.x＠gmail.com