- Dillo-dev - lists.mailman3.com

Good news from fltk!

by jcid＠dillo.org

Hi Johannes, On Tue, Apr 08, 2008 at 05:01:41PM +0200, Johannes Hofmann wrote: > Hi Jeremy, > > On Tue, Apr 08, 2008 at 07:35:25AM +0100, Jeremy Henty wrote: > > > > On Sat, Apr 05, 2008 at 05:01:52PM +0200, Johannes Hofmann wrote: > > > > > Attached is a patch that enables double buffering for partial screen > > > redraws (this is where the flickering is most annoying). You will > > > need at least version r6079 of fltk2 to test. > > > > OK, I've upgraded to the latest FLTK2 snapshot (r6087) and your patch > > (fixed version). Looks OK so far. Any tests I should run? > > Mostly I would be interested whether it still feels fast. And any > regressions you observe, of course... I found something that looks like a bug in double buffering (it doesn't happen with the previous code). If you: - ./dillo-fltk about:splash - scroll down 1 or 2 inches. - browse to another URL. - press right mouse button over Back button and return to the first page. You'll end looking to the page through a window artifact in the control panel. i.e. The page rendering seems to start from below the control PANEL. Please give it a look. -- Cheers Jorge.-

April 15, 2008

[patch] fix cookies freezing dillo problem

by jcid＠dillo.org

On Fri, Apr 11, 2008 at 11:49:26PM +0200, Andreas Kemnade wrote: > Hi Jorge, > > On Fri, 11 Apr 2008 15:34:49 -0400 > Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > > Note: What still puzzles me, is why accept() returns when > > there's nothing to read. > > > > Hmm, accept() returns when you call connect() on the other side. > Many TCP server programs send stuff to the client before receiving anything > from the client (like ssh servers, smtp servers) so there is nothing unusual > about that. > > So, normally you have > on cookies.dpi side: > accept() > returns after connect() on dillo side > read() > returns after write() on dillo side > > then on dillo side: > read() returns after write() on cookies.dpi side. > > As far as I understand in the race condition case you have: > > dillo cookies.dpi > connect(sock1,...) sock1=accept(....) > connect(sock2,...) (via a_Dpi_send_blocking_cmd) read(sock1,...) > write(sock2,...) (does not block, contents will be added to the recv queue) > read(sock2,...) > > and now, both sides are waiting for data,.... Thanks a lot for the explanation. -- Cheers Jorge.-

April 15, 2008

Re: patch: BUTTON

by jcid＠dillo.org

On Tue, Apr 15, 2008 at 04:16:55AM +0000, corvid wrote: > The old code showed uncertainty about whether one can interact with the > stuff inside a button. The spec doesn't say. I suspect you aren't > supposed to be able to. Firefox doesn't let you. If FF doesn't allow interaction it will be hardly found in the WEB, unless IE allows. :-P > When trying to look up info on button nesting, I discovered -- by crashing -- > that I needed to test whether I was in a form. However, I learned that > section 17.2.1 says: > > "The elements used to create controls generally appear inside a FORM element, > but may also appear outside of a FORM element declaration when they are used > to build user interfaces. This is discussed in the section on intrinsic > events. [p.254] Note that controls outside a form cannot be successful > controls [p.245]." > > ..but I'll make a separate patch for controls outside of forms. AFAICS this may be useful with client side scripts, but we're a long way from suporting scripts. -- Cheers Jorge.-

April 15, 2008

patch: image inputs

by jcid＠dillo.org

On Tue, Apr 15, 2008 at 01:23:47AM +0000, corvid wrote: > Jorge wrote: > > Committed! (with some changes). > > I just noticed that when you took out the other return, > DEBUG_MSG(10, "Html_input_image: unable to create image submit.\n"); > became unconditional. Ooops... Fixed & committed. -- Cheers Jorge.-

April 15, 2008

Re: patch: file input

by jcid＠dillo.org

On Sat, Apr 12, 2008 at 02:06:42AM +0000, corvid wrote: > Jorge wrote: > > On Fri, Apr 11, 2008 at 09:21:16PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Thu, Apr 10, 2008 at 04:13:56PM +0000, corvid wrote: > > > > > If I read in a file, delete that file, and try to read it in again > > > > > (uses E2EReload), the submit will send the (now empty) file because > > > > > a_Capi_get_buf() finds the (now empty) entry in cache. > > > > > So I'll have to find out where an a_Cache_entry_remove_by_url() should go. > > > > > > > > Yes. > > > > > > It looks like I'd have to figure out CCC for this, which would > > > likely be more trouble than it's worth. > > > > OK, I'll allocate some time to give it a look. > > Cool. Patch committed. After pondering whether to add a URL flag to discriminate a file-input loaded-file (to be able to free it later), the complexities of it being also used/displayed by another Dillo window (and the inherent races), and the necessary handling code, I preferred a local load. The async approach may be done, but the committed approach is simpler, gets the work done, and may be extended to handle multiple files. I also added a handy heuristic for content-type detection of files (it works well with the w3c validator). -- Cheers Jorge.-

April 15, 2008

patch: image inputs

by corvid＠lavabit.com

Jorge wrote: > Committed! (with some changes). I just noticed that when you took out the other return, DEBUG_MSG(10, "Html_input_image: unable to create image submit.\n"); became unconditional.

April 15, 2008

patch: image inputs

by jcid＠dillo.org

On Mon, Apr 14, 2008 at 09:30:17PM +0000, corvid wrote: > Jorge wrote: > > On Mon, Apr 14, 2008 at 05:22:44AM +0000, corvid wrote: > > > > > Committed! (with some changes). > > Wow. I expected to have to go through a few iterations... > > > > - If the image could not be loaded and you click on the alt text, the click > > > position is sent, even though it's not meaningful. > > > > Is there a standard/suggested behaviour in this case? > > All the spec said was: > "When a pointing device is used to click on the image, the form is submitted > and the click coordinates passed to the server. The x value is measured in > pixels [p.52] from the left of the image, and the y value in pixels [p.52]r > from the top of the image. The submitted data includes name.x=x-value and > name.y=y-value where "name" is the value of the name attribute, and x-value > and y-value are the x and y coordinate values, respectively." > > Let's see what our friend Firefox does: > - it _never_ sends name=value. > - for alt text, you get name.x=&name.y= > - if you tab to an image and press enter to submit, you get name.x=0&name.y=0 > - If you click on an image, you get name.x=n&name.y=m OK, so it looks like nobody uses it, in the not-in-minimal multibrowser set. Well, at least it will serve as a warm up for image maps! :-) -- Cheers Jorge.-

April 15, 2008

patch: image inputs

by corvid＠lavabit.com

Jorge wrote: > On Mon, Apr 14, 2008 at 05:22:44AM +0000, corvid wrote: > > > Committed! (with some changes). Wow. I expected to have to go through a few iterations... > > - If the image could not be loaded and you click on the alt text, the click > > position is sent, even though it's not meaningful. > > Is there a standard/suggested behaviour in this case? All the spec said was: "When a pointing device is used to click on the image, the form is submitted and the click coordinates passed to the server. The x value is measured in pixels [p.52] from the left of the image, and the y value in pixels [p.52]r from the top of the image. The submitted data includes name.x=x-value and name.y=y-value where "name" is the value of the name attribute, and x-value and y-value are the x and y coordinate values, respectively." Let's see what our friend Firefox does: - it _never_ sends name=value. - for alt text, you get name.x=&name.y= - if you tab to an image and press enter to submit, you get name.x=0&name.y=0 - If you click on an image, you get name.x=n&name.y=m

April 14, 2008

[patch] fix warning in html.cc

by jcid＠dillo.org

On Mon, Apr 14, 2008 at 05:20:41PM +0200, Johannes Hofmann wrote: > Hi, > > html.cc: In function 'void a_Html_form_event_handler(void*, form::Form*, void*)': > html.cc:4331: warning: 'input' may be used uninitialized in this function > > can be fixed with attached patch. Please review. It looks OK. Committed. -- Cheers Jorge.-

April 14, 2008

patch: image inputs

by jcid＠dillo.org

Hi, On Mon, Apr 14, 2008 at 05:22:44AM +0000, corvid wrote: > It works on the sites I tried, and the data sent looks right for other cases, Committed! (with some changes). > but: > > - To get click position, I used event_x() and event_y() in fltkui.cc because > they happened to have the right values in them and I didn't know the proper > place to look for this information. AFAIU (which is not that much in dw2 ;), it looks OK. > - If the image could not be loaded and you click on the alt text, the click > position is sent, even though it's not meaningful. Is there a standard/suggested behaviour in this case? > - I don't prevent the image from being loaded even when automatic image > loading is disabled (but I'm the only person who would notice anyway). No. "Img off" is a very useful option! Now, that traffic shapers degrade bandwidth, and that sometimes wireless is slow, not to mention dialups, it's quite handy. > (I would have to be able to get button 3 to bring up the image menu.) Could be. -- Cheers Jorge.-

April 14, 2008