May 2011 - Dillo-dev - lists.mailman3.com

Connection problems on Mac OS X 10.6.7

by jcid＠dillo.org

Hi Reza, On Mon, May 30, 2011 at 03:03:54PM -0500, reza farivar wrote: > [...] > Any suggestions what to look for next? Please try vanilla dillo with fltk-1.3 svn version r.8771. Or if you don't know how to get it from svn, patch your rc7 with this: http://fltk.org/newsgroups.php?s6029+gfltk.commit+v6048+T0 The FLTK devs are expecting our answer to close the issue. -- Cheers Jorge.-

May 31, 2011

Connection problems on Mac OS X 10.6.7

by rf.opensource＠gmail.com

On Mon, May 30, 2011 at 3:38 PM, corvid <corvid(a)lavabit.com> wrote: > reza wrote: > > As I was guessing, the busy wait is still there ONLY for the first tab > > (whether entered from command line or in the browser). But now any second > > tab will get stuff working, and I never see a page not loading again. So > for > > now I'm assuming this busy wait of the first tab is an orthogonal issue > and > > leave it alone (for now I can launch dillo as $src/dillo www.yahoo.com > > www.google.com and they both load fine). > > > > So, it seems the bug stems somewhere in the stylesheets support, and > perhaps > > the repush issue was pointing to this as well. > > Do you have any problems when repushes are triggered by meta tags > changing the character encoding (Html_tag_open_meta() )? > There is no problem with them with the CSS support disabled. I can open a page with META and charset in the HEAD ( http://www.spartacus.schoolnet.co.uk/USAPstieglitz.htm) and it opens fine. I successfully see ">>>> a_Nav_repush <<<<" in the logs. With CSS support enabled, the same page with META (and a bit of CSS) does not load. Interestingly, loading it DOES NOT force a repush, even though it should since that page has <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> Note: seeing a ">>>> a_Nav_repush <<<<" in the logs is more of an indication that something good happened which opens the clog. So the question is, what happens during CSS parsing that forces a repush? Or looking at the problem the other way, why disabling the CSS support makes pages work without a repush, while having the CSS clogs them until something happens that a repush takes place? > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

May 31, 2011

Connection problems on Mac OS X 10.6.7

by corvid＠lavabit.com

reza wrote: > As I was guessing, the busy wait is still there ONLY for the first tab > (whether entered from command line or in the browser). But now any second > tab will get stuff working, and I never see a page not loading again. So for > now I'm assuming this busy wait of the first tab is an orthogonal issue and > leave it alone (for now I can launch dillo as $src/dillo www.yahoo.com > www.google.com and they both load fine). > > So, it seems the bug stems somewhere in the stylesheets support, and perhaps > the repush issue was pointing to this as well. Do you have any problems when repushes are triggered by meta tags changing the character encoding (Html_tag_open_meta() )?

May 30, 2011

Connection problems on Mac OS X 10.6.7

by rf.opensource＠gmail.com

On Mon, May 30, 2011 at 6:43 AM, Benjamin Johnson <obeythepenguin(a)gmail.com>wrote: > On Mon, 30 May 2011 06:40:53 -0400, reza farivar <rf.opensource(a)gmail.com> > wrote: > > So, what is this repush business? And do you think it can have anything to >> do with the bug I'm seeing? >> > > IIRC, a "repush" is where it reloads the page from cache. I think it does > that, for example, when it loads a style sheet. > > Come to think of it, try turning CSS and images off (under the Tools menu) > and see what happens. I don't know if it will make any difference, but if > it does, then there might be something going on in that code. Excellent suggestion Benjamin! It didn't work from the tools menu, but once I added load_stylesheets=NO parse_embedded_css=NO to dillorc and make clean;make again, it's now much much better! Aside from the first tab (see below), I never have any connections problems now. As I was guessing, the busy wait is still there ONLY for the first tab (whether entered from command line or in the browser). But now any second tab will get stuff working, and I never see a page not loading again. So for now I'm assuming this busy wait of the first tab is an orthogonal issue and leave it alone (for now I can launch dillo as $src/dillo www.yahoo.com www.google.com and they both load fine). So, it seems the bug stems somewhere in the stylesheets support, and perhaps the repush issue was pointing to this as well. Any suggestions what to look for next? > > > P.S. In my opinion (and ignoring this pesky bug) the single most important >> feature lacking in dillo is support for floating elements. As soon as we >> have it, dillo is as good as NetSurf (http://www.netsurf-browser.org/) in >> functionality with half the memory footprint. As far as I can tell NetSurf >> is the current champ of low resource + good enough functionality, while >> IMHO >> dillo has more potential. >> > > Agreed. (My favorite thing about Dillo: what other web browser in 2011 > still fits on one floppy disk?) > > Cheers, > ~Benjamin > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

May 30, 2011

Connection problems on Mac OS X 10.6.7

by rf.opensource＠gmail.com

On Mon, May 30, 2011 at 12:32 PM, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > On Mon, May 30, 2011 at 05:40:53AM -0500, reza farivar wrote: > > Well after 2 days of chasing the non-connection bug, I'm still not > > successful in locating the bug. But first a few points: > > > > 1. Mac-Fltk 1.3 indeed contains code for "select"ing socket events. I > found > > this myself and later Manolo verified it. The comment that Jorge > mentioned > > is a leftover, but the code is there. In fact it runs in a pthread, and > the > > whole system wouldn't work without it anyway. > > What did Manolo answer exactly? > Here's what I asked and his answer: " >Hi Manolo, >I'm working with "Dillo browser" people to get their browser, which uses FLTK 1.3, to compile and run on Mac OS X. >We have come across a bug in which the browser waits forever in a busy loop waiting for something from a connecting socket, which seems to come from FLTK. >Specifically, during the busy wait period it seems the program is stuck in fl_mac_flush_and_wait() from FL_cocoa.mm. >fl_mac_flush_and_wait in turn calls fl_wait(). I noticed that you have left a comment on top of fl_wait() mentioning: > >\todo there is no socket handling in this code whatsoever > >I also checked the fl_wait function for the unix versions in FL_x.cxx, and in there the function issues the "select" system call, while in the mac function it seems it's just a timeout loop? >Can you please verify if this is indeed a missing functionality waiting to be fixed? Is there a quick fix? Hi Reza, I have no idea why this comment is there. It was in the Carbon version, and I didn't remove it. I know that Fl::add_fd() on a pseudoterminal works correctly (I use that in my app). I have checked with the button demo program (after changing #if 0 into #if 1) that Fl::add_fd() also works on stdin. Thus, my idea is that there was no missing functionality. But I may be wrong, and you may have discovered a bug. You would then have to file an STR in FLTK for that, and describe the problem as accurately as possible. Best wishes, Manolo ============================================================== Hi Reza, Below is the logical flow that handles file descriptors declared to FLTK with Fl::add_fd(). It is identical in essence to what it was during the Carbon era. The only change is that events are created, queued, and fetched the Cocoa way. in main thread: fl_mac_flush_and_wait fl_wait do_queued_events //start a thread devoted to fd handling: if ( dataready.GetNfds() ) dataready.StartThread(); //continue below in fd-handling thread: This thread runs DataReady::DataReadyThread() that does select() on current fd's. When data is ready, DataReadyThread() creates an application-defined event of subtype FLTKDataReadyEvent, puts it in the event queue, and the thread finishes. in main thread (continued): //the next event is fetched from the event queue: NSEvent *event = [NSApp nextEventMatchingMask:NSAnyEventMask ... //and the sendEvent function is called: [FLApplication sendEvent:event]; //in: (void)sendEvent:(NSEvent *)theEvent if the event type is NSApplicationDefined and the subtype is FLTKDataReadyEvent, call processFLTKEvent() call DataReady::HandleData() call the fd callback to process this data. Hoping this helps. Manolo =================================================================== Hi Reza, The threads demo program runs well on Mac OS. This shows that Fl::add_fd() is also correct for a pipe, as used in this program. I never tested a socket, though. " > > 2. So I'm now convinced the problem is somewhere in Dillo. > > What did convince you? > The demo programs of FLTK work fine, and FLTK does issue a "select" system call in a thread. See in FLTK: src/Fl_cocoa.c, lines 364 to 409, and Manolo's comments above. On the other hand it seems the bug has to do with the contents of the pages being loaded. If the contents are such that it doesn't create conditions for a repush, things get stuck. Otherwise If the contents do force a repush in dillo, the other previous tabs start to load their contents. Finally as I mentioned earlier it seems the busy loop is an orthogonal issue, which always happens for the first tab, no matter what the contents are. It is probably a red herring, which sent us to the path of looking at fl_mac_flush_and_wait. But as soon as I open a second tab and enter a URL the busy wait stops and never happens again. But since the non-connection issue remains for the rest of the tabs, it makes me believe the non-connection bug is a separate issue to the busy wait of first tab, and has to do with conditions of a repush. > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

May 30, 2011

Connection problems on Mac OS X 10.6.7

by jcid＠dillo.org

On Mon, May 30, 2011 at 05:40:53AM -0500, reza farivar wrote: > Well after 2 days of chasing the non-connection bug, I'm still not > successful in locating the bug. But first a few points: > > 1. Mac-Fltk 1.3 indeed contains code for "select"ing socket events. I found > this myself and later Manolo verified it. The comment that Jorge mentioned > is a leftover, but the code is there. In fact it runs in a pthread, and the > whole system wouldn't work without it anyway. What did Manolo answer exactly? > 2. So I'm now convinced the problem is somewhere in Dillo. What did convince you? -- Cheers Jorge.-

May 30, 2011

Connection problems on Mac OS X 10.6.7

by obeythepenguin＠gmail.com

On Mon, 30 May 2011 06:40:53 -0400, reza farivar <rf.opensource(a)gmail.com> wrote: > So, what is this repush business? And do you think it can have anything > to > do with the bug I'm seeing? IIRC, a "repush" is where it reloads the page from cache. I think it does that, for example, when it loads a style sheet. Come to think of it, try turning CSS and images off (under the Tools menu) and see what happens. I don't know if it will make any difference, but if it does, then there might be something going on in that code. > P.S. In my opinion (and ignoring this pesky bug) the single most > important > feature lacking in dillo is support for floating elements. As soon as we > have it, dillo is as good as NetSurf (http://www.netsurf-browser.org/) in > functionality with half the memory footprint. As far as I can tell > NetSurf > is the current champ of low resource + good enough functionality, while > IMHO > dillo has more potential. Agreed. (My favorite thing about Dillo: what other web browser in 2011 still fits on one floppy disk?) Cheers, ~Benjamin

May 30, 2011

Connection problems on Mac OS X 10.6.7

by rf.opensource＠gmail.com

Well after 2 days of chasing the non-connection bug, I'm still not successful in locating the bug. But first a few points: 1. Mac-Fltk 1.3 indeed contains code for "select"ing socket events. I found this myself and later Manolo verified it. The comment that Jorge mentioned is a leftover, but the code is there. In fact it runs in a pthread, and the whole system wouldn't work without it anyway. 2. So I'm now convinced the problem is somewhere in Dillo. Here is what I have nailed it down to so far: It seems to me that the problem might have to do with "repush". I run the program as: $src/dillo | grep Nav_, and I can get no connection regardless of the websites until I enter a URL that forces a repush. I have a list of websites that do not entice a repush (some of the times): www.yahoo.com, www.google.com, http://www.maketemplate.com/htmlgenerator/htmlout.php autos.yahoo.com, and as long as I keep entering any of these addresses after a fresh start and I don't see a repush message in terminal, I will get nothing in my tabs. As soon as I enter a URL that does entice a repush, the whole system works, including the previous blocked tabs. If later on again a tab doesn't load up, I can make the system work by opening other tabs and entering URLs until a repush happens. So, what is this repush business? And do you think it can have anything to do with the bug I'm seeing? By the way, the busy wait issue seems to be a different bug and just happens to coincide. No matter which website I enter, the first tab (whether I enter URL manually or on command line) never connects and always forces a busy wait. As soon as I open another tab and enter any URL, regardless of whether it will do a repush and open the clog or not, the busy-wait ends. P.S. In my opinion (and ignoring this pesky bug) the single most important feature lacking in dillo is support for floating elements. As soon as we have it, dillo is as good as NetSurf (http://www.netsurf-browser.org/) in functionality with half the memory footprint. As far as I can tell NetSurf is the current champ of low resource + good enough functionality, while IMHO dillo has more potential. -Reza On Fri, May 27, 2011 at 7:11 PM, reza farivar <rf.opensource(a)gmail.com>wrote: > > > On Fri, May 27, 2011 at 3:53 PM, Jorge Arellano Cid <jcid(a)dillo.org>wrote: > >> On Fri, May 27, 2011 at 03:25:32PM -0500, reza farivar wrote: >> > On Fri, May 27, 2011 at 3:18 PM, Jorge Arellano Cid <jcid(a)dillo.org> >> wrote: >> > >> > > On Fri, May 27, 2011 at 01:53:08PM -0500, reza farivar wrote: >> > > > On Fri, May 27, 2011 at 12:46 PM, Benjamin Johnson < >> > > obeythepenguin(a)gmail.com >> > > > > wrote: >> > > > >> > > > > On Fri, 27 May 2011 13:38:43 -0400, reza farivar < >> > > rf.opensource(a)gmail.com> >> > > > > wrote: >> > > > > >> > > > > Yes. Well, the only plugin I could see is the save button on the >> > > panel, >> > > > >> and >> > > > >> it can successfully navigate the filesystem and save a page >> correctly. >> > > > >> >> > > > > >> > > > > That one isn't a plugin, actually. Does the bookmarks button >> work? >> > > > > >> > > > > Yes, bookmarks work. (This is a bit of strange implementation of >> > > bookmarks, >> > > > no? took me a bit to find out difference of section and item) >> > > >> > > Good! >> > > >> > > If you can see the html page from the bookmarks, it means the >> > > whole dpi framework is working on Mac; they communicate using >> > > sockets. >> > > >> > > So it seems the main thing pending is socket support in fl_wait >> > > for Mac (see my previous email). >> > > >> > >> > Yes, I also think it's the source of this problem (see my other email). >> > >> > But what really perplexes me is that this happens only when I enter a >> URL >> > manually. When I follow links from one page to another it never happens. >> Are >> > you guys using different (FLTK) functions when opening a new page or >> > following a links (whether in the same tab or in a new tab)? >> >> No, but when you hit ENTER, FLTK has a chance to queue events >> and zero-wait timeouts for the widget callback and necessary >> stuff. OTOH, clicking a link goes another path (inside dillo). >> >> Can you point me to parts of code for either of these two code paths? > Filename / line number should suffice. > > >> >> > And it seems that as Dillo "warms up" I get less of this problem... >> >> Timimg issues are moody. >> e.g. Have you tried dillo listening a good mp3? :-) >> >> BTW, good you asked Manolo G. >> (FWIW, FLTK2 has code for socket events in Mac). >> >> -- >> Cheers >> Jorge.- >> >> _______________________________________________ >> Dillo-dev mailing list >> Dillo-dev(a)dillo.org >> http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >> > >

May 30, 2011

Re: downloads gui appearance

by corvid＠lavabit.com

Jorge wrote: > On Sat, May 28, 2011 at 05:19:53PM +0000, corvid wrote: > > > > Also, I just tried downloading two files at once, and...I imagine > > the window is supposed to resize or something, but it didn't. > > No the idea is it to keep its size, and have a scroll > (usually long downloads are left as a small window that you > skim once in a while). > > You can resize it manually though. I didn't have a scrollbar.

May 28, 2011

Re: downloads gui appearance

by jcid＠dillo.org

On Sat, May 28, 2011 at 05:19:53PM +0000, corvid wrote: > > Also, I just tried downloading two files at once, and...I imagine > the window is supposed to resize or something, but it didn't. No the idea is it to keep its size, and have a scroll (usually long downloads are left as a small window that you skim once in a while). You can resize it manually though. -- Cheers Jorge.-

May 28, 2011