- Dillo-dev - lists.mailman3.com

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

[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