March 2008 - Dillo-dev - lists.mailman3.com

[BUG]: anchors break when a page includes '<meta http-equiv="Content-Type" ...'
by onepoint＠starurchin.org May 11, 2008

May 11, 2008

If you navigate to a page with a '<meta http-equiv="Content-Type" ...' in the head element then any anchor in the URL is ignored. (This breaks my local cinema's web page because it puts listings and film descriptions on the same page and links them with anchors.) I think the reason is that the meta element forces the page to be reloaded by Nav_push() and this does not call a_Nav_expect_done(). Unfortunately a_Nav_expect_done() is responsible for calling a_UIcmd_set_scroll_by_fragment(), so any page pulled in by Nav_push() does not scroll to the anchor. Any ideas how to fix this? I having a hard time getting my head around this bit of the code. Regards, Jeremy Henty

4 16

[PATCH]: Fixing https step 1: Have a basic dpi dialog window working again
by Christian.Kellermann＠nefkom.net April 11, 2008

April 11, 2008

Skipped content of type multipart/mixed

4 9

(place->corvid) popup menus
by corvid＠lavabit.com April 2, 2008

April 2, 2008

Got back to looking at why popup menus are offset by the height of the control panel, and // Make the popup a child of the calling UI object ((Group *)bw->ui)->add(pm); caught my eye. I thought perhaps if I made them children of Main instead, they would work. But first I tried commenting it out completely -- and now everything seems to work fine. The popups even remember the previous item chosen, which would allow the removal of click-to-load for images. Does anybody remember whether the add() call was for some reason that I haven't noticed? (Jorge cleared the moderation bit for me, so I think you will get this mail!)

3 6

From the BLFS project: [theoldfellow@gmail.com: Dillo - going, going....]
by onepoint＠starurchin.org March 31, 2008

March 31, 2008

The Beyond Linux From Scratch project is removing Dillo Classic because they don't want to list unsupported GTK1 applications (in fact they are looking to ditch GTK1 completely). They seem pretty keen on Dillo-FLTK though! Jeremy Henty ----- Forwarded message from TheOldFellow <theoldfellow(a)gmail.com> ----- From: TheOldFellow <theoldfellow(a)gmail.com> To: blfs-dev(a)linuxfromscratch.org Subject: Dillo - going, going.... Date: Mon, 31 Mar 2008 11:14:42 +0100 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.1 Well no one screamed that it was their favourite web browser, so I'll comment it out of the book later today. As an aside, I built Dillo2, still very alpha, with FLTK2, in Beta. The result is quite good. Lightning fast, and some nice features as a browser to build first and read BLFS with while you build the GTK2 and Firefox ziggurat. I'll put a wiki page together for it later too. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page ----- End forwarded message -----

1 0

[patch] scroll cleanup
by Johannes.Hofmann＠gmx.de March 31, 2008

March 31, 2008

Hello, as promised here comes my attempt to cleanup the scrolling code a bit. scrollTo () is now the real method and scroll () is just a helper. I think that is more natural than the other way round. I also moved the call to updateCanvasWidgets () out of the draw () method again as I think draw () should not modify things if possible. I hope I have not reintroduced the widget scrolling bug place has just fixed. Can you verify this? Cheers, Johannes

3 2

Re: patch: Cookies_parse_one()
by jcid＠dillo.org March 29, 2008

March 29, 2008

On Thu, Mar 27, 2008 at 05:27:18PM +0000, place wrote: > I had to turn on cookies to try something, and the very first cookie I > saw threw the dpi into an infinite loop. > "TRK%5FLastLoginID=; expires=Fri, 27-Mar-2009 04:00:00 GMT; path=/" > > Instead of returning immediately on error, it eats its broken cookie up now. > And I added some dFree(attr)s. Good, thanks for the fixes; it's much simpler to debug functions that have a single return point. Committed. > > Oh, and the "catched" in Cookies_parse_string() should be "caught". > Should've put that in the patch, but I forgot. Committed. -- Cheers Jorge.-

1 0

Re: a_Url_cmp()
by jcid＠dillo.org March 29, 2008

March 29, 2008

On Sat, Mar 29, 2008 at 04:25:42AM +0000, place wrote: > 1. I happened to run into a preexisting bug in a_Url_cmp(). > > I hooked up the dialog code as the others had done for https, and the > first URL I tried was a redirect that goes > http://something -> https://something. The urls are identical except for > the scheme. It broke because a_Url_cmp() has > > (st = URL_STR_FIELD_I_CMP(A->scheme, B->scheme) == 0))) > instead of > (st = URL_STR_FIELD_I_CMP(A->scheme, B->scheme)) == 0)) Committed. > 2. The mail I tried to send some days back from my new account(*) also > happened to be about a_Url_cmp(). When I was playing with file inputs, > I generated the URL file:///something, with file:/something already in > cache. Cache did not find it because the authority of one was NULL and > the authority of the other was "". URL_STR_FIELD_I_CMP thinks those are > different things. Which is possible. Knowing how weird the URL spec gets, > the code might reflect a genuine difference, but sounds more like an error. Yes, current URL handling follows the spec. The problem is that the rest of dillo is using URLs like file:/something freely, when they should be file:///something. It should be easy to switch the file server dpi to generate "file:///"-prefixed URLS, and the input location to also normalize file:/ prefixed ones. But, if they appear in an external html page, it may be better to make the URL code normalize it (or check what other browsers do). > That I should run into these two issues at the very same time that I'm > trying to change a_Url_cmp() for url->data is a strange coincidence. Peer reviewing is always an asset. > > * And it receives list mail just fine. Andreas seemed to think that > as long as I'm subscribed, I shouldn't have any moderation problems. > Strange. Out of my control, anyway. I gave a look at the list settings. Please let me know your new email address to find whether I can do something to enable it. BTW, with the new patch for "missing widgets", when I first went to http://lists.auriga.wearlab.de/cgi-bin/mailman/admin/dillo-dev the Password input widget was missing! (it worked the next tries). -- Cheers Jorge.-

1 0

patch: widget scrolling
by place＠gobigwest.com March 29, 2008

March 29, 2008

I've had lots of trouble with widgets disappearing because my machine is too slow to keep up. But today I had the good fortune to happen to stumble upon updateCanvasWidgets()... Johannes, are there any unintended consequences to this fix?

3 3

patch: URL data as a Dstr
by place＠gobigwest.com March 29, 2008

March 29, 2008

This is part one in a series for file inputs. Parts two and three are written. Parts four and five are contemplated. Maybe a part six if I feel like it. Part three is the one that makes it at least appear to work, though I'll need help in testing at that point. HTTPS note: If https does remain a dpi, somebody will have to decide what they want to do with Capi_dpi_build_cmd() if http_query can contain NULLs.

2 1

ComplexButton crashing
by place＠gobigwest.com March 26, 2008

March 26, 2008

For you dw people... I am working on getting ComplexButton to work (image inputs), and it would segfault when I'd close the bw. In FltkComplexButtonResource::createNewWidget, the button's child is a view. When the button is destroyed, since the button is a Group, its children get destroyed. Later on, the layout is being destroyed, and it deletes TopLevel. The toplevel widget destructor calls layout->removeWidget(), which tries to iterate through the views. To make the problem go away, I added: fltkcomplexbutton.hh: ~ComplexButton() {remove_all();} but I don't know any of this code well enough to know what _should_ be going on.

2 4