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

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

[patch] fix warning in html.cc

by corvid＠lavabit.com

Johannes wrote: > 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 Oops. I thought it was strange that I hadn't gotten this warning, and now I learn that one does not get -Wuninitialized if -O is turned off. I've been compiling without -O to make debugging easy.

April 14, 2008

[patch] fix warning in html.cc

by Johannes.Hofmann＠gmx.de

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. Cheers, Johannes

April 14, 2008

patch: image inputs

by corvid＠lavabit.com

It works on the sites I tried, and the data sent looks right for other cases, 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. - 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. - 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). (I would have to be able to get button 3 to bring up the image menu.)

April 14, 2008

[patch] make ComplexButton work

by jcid＠dillo.org

On Sun, Apr 13, 2008 at 09:24:35PM +0200, Johannes Hofmann wrote: > Hi, > > this patch fixes ComplexButton - at least it works here now :-) > The patch includes the ComplexButton destructor proposed by place > and enables the ComplexButton code in dw-ui-test. > It requires my last FltkViewBase::draw() patch. OK. Committed both. -- Cheers Jorge.-

April 14, 2008

[patch] cleanup FltkViewBase::draw

by jcid＠dillo.org

On Sun, Apr 13, 2008 at 09:05:35PM +0200, Johannes Hofmann wrote: > Hi, > > here comes a cleanup of FltkViewBase::draw(). It had grown too > complicated... > This patch also fixes two issues with nested views as they will > exist with ComplexButtons. Committed. -- Cheers Jorge.-

April 13, 2008