- Dillo-dev - lists.mailman3.com

replies from a dillo user (fwd)

by Jorge Arellano Cid

---------- Forwarded message ---------- Date: Fri, 9 May 2003 22:32:00 +0100 From: Marius Kempe <tanadan(a)tanadan.uklinux.net> To: jcid(a)softhome.net Subject: replies from a dillo user Hello! I would just like to say that I have been using dillo for the past 6 months? or so and I really like it. I would even consider contributing to the project if I had any money, but keep up the good work! :-) I guess there's not much point in this letter, just saying 'thank you'. -- Tanadan Which would win in a fight, a monkey, a robot, a pirate, or a ninja?

May 23, 2003

Dillo and Zaurus

by dontodd＠columbus.rr.com

I just got a Zaurus SL-5500 and was wondering if anyone has built Dillo for that. I'm running Open Zaurus 3.2. Where would I begin? Sorry for such a newb question! Todd

May 23, 2003

Re: [Dillo-dev] Strange post data from <input type=image...

by Andreas Kemnade

On Fri, 23 May 2003 11:07:14 +0300 (EEST) Madis Janson <madis(a)ats.cyber.ee> wrote: > On Fri, 23 May 2003, Andreas Kemnade wrote: > > > On Fri, 23 May 2003 02:19:47 +0300 (EEST) > > Madis Janson <madis(a)ats.cyber.ee> wrote: > > > > > So the behaviour is *imho* undefined. It would be helpful, when someone > > > could confirm that i've understood the standard correctly (or find out a > > > correct browser behavior). Checking out other browsers behavior with input > > > images having a value attribute would also be useful (i just don't have > > > enough free time for this at moment, sorry). > > > > > Very interesting: > > <input type="image" name= > > "CONFIRM" value="bla" src="ecoupon-abschicken.gif" border="0" height="13"> > > > > netscape 4.7 sends the same as without value and mozilla sends an additional > > CONFIRM=bla > > > Then the patch should behave like mozilla. Did it fixed the problem? No, it didn't fix the problem. But the patch did what it should (sent a form to netcat) Greetings Andreas Kemnade

May 23, 2003

Re: [Dillo-dev] Strange post data from <input type=image...

by Madis Janson

On Fri, 23 May 2003, Andreas Kemnade wrote: > On Fri, 23 May 2003 02:19:47 +0300 (EEST) > Madis Janson <madis(a)ats.cyber.ee> wrote: > > > So the behaviour is *imho* undefined. It would be helpful, when someone > > could confirm that i've understood the standard correctly (or find out a > > correct browser behavior). Checking out other browsers behavior with input > > images having a value attribute would also be useful (i just don't have > > enough free time for this at moment, sorry). > > > Very interesting: > <input type="image" name= > "CONFIRM" value="bla" src="ecoupon-abschicken.gif" border="0" height="13"> > > netscape 4.7 sends the same as without value and mozilla sends an additional > CONFIRM=bla > Then the patch should behave like mozilla. Did it fixed the problem?

May 23, 2003

Re: [Dillo-dev] Strange post data from <input type=image...

by Andreas Kemnade

On Fri, 23 May 2003 02:19:47 +0300 (EEST) Madis Janson <madis(a)ats.cyber.ee> wrote: > So the behaviour is *imho* undefined. It would be helpful, when someone > could confirm that i've understood the standard correctly (or find out a > correct browser behavior). Checking out other browsers behavior with input > images having a value attribute would also be useful (i just don't have > enough free time for this at moment, sorry). > Very interesting: <input type="image" name= "CONFIRM" value="bla" src="ecoupon-abschicken.gif" border="0" height="13"> netscape 4.7 sends the same as without value and mozilla sends an additional CONFIRM=bla Greetings Andreas Kemnade

May 23, 2003

Re: [Dillo-dev] Strange post data from <input type=image...

by Madis Janson

On Thu, 22 May 2003, Andreas Kemnade wrote: > <input type="image" name="CONFIRM" src="ecoupon-abschicken.gif" border="0" height="13"> > This line produces for example(when you have clicked on that button): > CONFIRM=&CONFIRM.x=7&CONFIRM.y=9 > > With netscape4.7 and mozilla, only > CONFIRM.x=7&CONFIRM.y=9 > is sent. I have found one form which seems not to work with dillo but with > netscape. Unfortunately, that is a form for a transferal from a bank and it > works fine with the demo account, so that is really hard to test. > > Does anyone know if that is a bug in dillo and/or how to fix that? > HTML 4.01 standard section 17.13.2 (Successful controls) tells: | A successful control is "valid" for submission. Every successful control | has its control name paired with its current value as part of the | submitted form data set. A successful control must be defined within a | FORM element and must have a control name. and | If a control doesn't have a current value when the form is submitted, | user agents are not required to treat it as a successful control. So the behaviour is *imho* undefined. It would be helpful, when someone could confirm that i've understood the standard correctly (or find out a correct browser behavior). Checking out other browsers behavior with input images having a value attribute would also be useful (i just don't have enough free time for this at moment, sorry). It may be possible to achieve compliance with other browsers using this patch: ================================================================= diff -pru -x CVS -x configure -x 'aclocal*' -x 'Makefile*' -x config.h.in cvs/dillo/src/html.c dillo/src/html.c --- cvs/dillo/src/html.c 2003-05-01 16:58:30.000000000 +0300 +++ dillo/src/html.c 2003-05-23 01:47:53.000000000 +0300 @@ -2900,7 +2993,8 @@ static void Html_submit_form(GtkWidget * break; case DILLO_HTML_INPUT_IMAGE: if (input->widget == submit) { - Html_append_input(DataStr, input->name, input->init_str); + if (input->init_str) + Html_append_input(DataStr, input->name, input->init_str); Html_append_clickpos(DataStr, input->name, click_x, click_y); } break; @@ -3123,7 +3217,8 @@ static void Html_tag_open_input(DilloHtm } Html_add_input(form, inp_type, widget, name, - (init_str) ? init_str : "", NULL, init_val); + (init_str || inp_type == DILLO_HTML_INPUT_IMAGE) + ? init_str : "", NULL, init_val); if (widget != NULL && inp_type != DILLO_HTML_INPUT_IMAGE) { if (inp_type == DILLO_HTML_INPUT_TEXT || ================================================================= I only checked, that it doesn't crash on first click on input image, so its mostly untested and may not help and/or be broken in some ways.

May 23, 2003

Strange post data from <input type=image...

by Andreas Kemnade

<input type="image" name="CONFIRM" src="ecoupon-abschicken.gif" border="0" height="13"> This line produces for example(when you have clicked on that button): CONFIRM=&CONFIRM.x=7&CONFIRM.y=9 With netscape4.7 and mozilla, only CONFIRM.x=7&CONFIRM.y=9 is sent. I have found one form which seems not to work with dillo but with netscape. Unfortunately, that is a form for a transferal from a bank and it works fine with the demo account, so that is really hard to test. Does anyone know if that is a bug in dillo and/or how to fix that? Greetings Andreas Kemnade

May 22, 2003

manufacturer of garments and bags in China

by Rachel

Dear Sir or Madam, I have the pleasure to know your esteemed corp. We are a manufacturer & exporter of garments and bags in Quanzhou, China. I think we can cooperate and supply you with garments as you need. The following is some introductions about our company. Set up: 1988 Type: manufacturer & exporter Product: knitted garments and bags Employees: 1300 persons ( garments factory: 500 bags factory: 800) Product data: product (main items) capacity(/year) brief 2,000,000dzs baby body 1,800,000dzs boxer short 200,000dzs pajama 50,000dzs soft bag 1,500,000pcs hard bag 500,000pcs Mimn order: 300dzs for garments Payment: irrevocable L/C at sight Bank: BANK OF CHINA Our garment factory mainly specialize in Lady's and men's underwear, children's wear, baby's wear, pajama, boxer shorts, T-shirt, etc. The materials we often use are cotton, T/C, Polyester, Polyamide, Elasthan, and Polyamide. Our products are design with PAD system, produced with advanced equipment, processed in highly quality control system with seasoned workmanship and high efficiency. Our main market is Europe, Australia, Japan and America. We also accept the orders designed and required by costumers. You can see some pictures of our samples through our web http://www.senwer.com. (For more pictures in your interesting, pls kindly contact us directly). Our bag factory was founded in 1988, too. We produce all kinds of bags, including suitcase, backpack, travel bag, shoulder bag, sport bag, trolley, camera bag, tote bag, school bag, computer case, luggage,waist bag, notecase, etc. And the goods have met a great favor in the Europe countries, Australia and America because of their good quality, beautiful design and competitive price. Thank you very much. Hope you will give us an opportunity to do business together and we will try our level best to fulfill your present requirement. Should you therefore need any more details for your clarification, pls do not hesitate to contact us. And you are welcome to visit our factories. With best regards Rachel Wang Mob:0086-13960286700 E-mail:rachel@senwer.com Jason Chen Mob:0086-13959893400 E-mail: jasonchen(a)senwer.com Vicki Wang Mob:0086-13960228599 E-mail: vicki(a)senwer.com ----------------------------------------------------------------------------- SENWER GARMENTS CO., LTD. ADD: Room F202, Fugui Renjia Building, Liuguan Road, Quanzhou, Fujian, China. Tel: 0086-595-2506700 Fax: 0086-595-2563400 P.C.:362000 Http://www.senwer.com E-mail: senwer(a)public.qz.fj.cn -----------------------------------------------------------------------------

May 21, 2003

Re: saving entered datas in forms

by Nikita V. Borodikhin

On Tue, 20 May 2003 13:39:23 -0400 (CLT) Jorge Arellano Cid <jcid(a)softhome.net> wrote: > PS: With regard to "saving entered datas in forms", after some > WEB research, I found it's somewhat obscure to know whether > there's a way to do it the "standard way". Some sources like > caching and some others hate it. > > As we know, caching form data can be a huge security threat. > That mainly depends on what data is remembered and on the user's > environment. > > For instance, some banks refuse to work with browsers that > cache the pages (verifying browser signatures), with a view to > protect their customers from eavesdropping (as it could happen > when they make an operation and leave for a while to the > bathroom; Any person in the same office can click a few > Backs and read what was done and read the hand-typed camps). > > I'd appreciate some more research on this topic (certainly a > time-comsuming task I can't work on now). To know what some > serious browsers do, is a good starting point. One of our > objectives is personal security and privacy, and it takes a lot > of work. Jorge, at least while we wouldn't have normal cache in dillo (I mean cached page expiration) it would not be much reason to work on it further. After that approach must be diffent, values should be saved in cache (or in file ?) not in browser window. Until normal cache to appear in main branch there is not much reason to reimplement subj, IMHO. Nikita

May 21, 2003

entities display

by Nikita V. Borodikhin

On Tue, 20 May 2003 13:39:23 -0400 (CLT) Jorge Arellano Cid <jcid(a)softhome.net> wrote: > Hi Nikita, Hello, Jorge ! > Now, considering the current development plan, it'd be good to > have an interim workaround. > > After reviewing the implementation in the patch, I'd prefer not > to intermix it with the current (correct but incomplete) way of > handling entities. > > For instance, defining another entities table that's to be used > when the entity is not found in the current one is a good way to > separate the workaround code! > > I'd like to add to this new table some important numeric > character references (UTF-8) that are usually found in web pages > these days. Things like: > > "—" > "’" > "“" > "”" > > This could help our rendering while we get to GTK+2. > Please let me know if you want to improve it this way! > > Cheers > Jorge.- Jorge, the current way to display entities do not satisfy me because it throws away any entity which code is more than 255. Is there any reason to leave table without representations in place and add a new one _with_ them which differs only in representations field and (possible) bigger number of entities ? In future (GTK2 internals) all representations definition and use could be cut from source code and I don't see any problem or pain with it, corresponding changes will be not so big. IMHO all progress we can do now is entering more entities in table. In any case I interested in further progress in this way. P.S. Entities you mention cannot be translated from UCS2 (encoding used in HTML numeric entities) to UTF-8. Lynx/links do not show that also. Yours, Nikita

May 21, 2003