Lock-up starting NetSurf from Messenger link
If NetSurf is already running, selecting a link in an incoming message in Messenger works and NetSurf opens the web page. However, if NetSurf is not running (but Alias$URIOpen_... and Alias$URLOpen_... are set to run it), and I click on a link in a Messenger message there is a pause, then the border of a dialogue window is drawn (with no content) and the machine locks up. The mouse pointer still moves but Alt Break etc. can't break out of the lock-up. If I start NetSurf from other applications, or my own Basic functions that look at Alias$URLOpen_... and do a Wimp_StartTask, it works OK. So it seems that whatever Messenger is doing to fire up NetSurf causes this problem. I thought I would ask if any other NetSurf users have seen the problem (then I'll probably report it to RComp). I'm running NS r4259 with Messenger 5.12 on VirtualRPC-SE -- Mike Hobbs
Re: Lock-up starting NetSurf from Messenger link
On Tue, 5 Aug 2008, Mike Hobbs wrote: If NetSurf is already running, selecting a link in an incoming message in Messenger works and NetSurf opens the web page. However, if NetSurf is not running (but Alias$URIOpen_... and Alias$URLOpen_... are set to run it), and I click on a link in a Messenger message there is a pause, then the border of a dialogue window is drawn (with no content) and the machine locks up. The mouse pointer still moves but Alt Break etc. can't break out of the lock-up. What kind of dialogue are we talking about here? A Wimp error box or something else? If I start NetSurf from other applications, or my own Basic functions that look at Alias$URLOpen_... and do a Wimp_StartTask, it works OK. So it seems that whatever Messenger is doing to fire up NetSurf causes this problem. I thought I would ask if any other NetSurf users have seen the problem (then I'll probably report it to RComp). It may be useful to run Wimpmon and have it log the relevant Wimp message blocks to disc in raw format. John.
Forms with maxsize=""
I am unable to enter data in some input fields on a form. The reason seems to be the attribute maxsize="". The form seems to work on Windoze browsers. I suspect that the null string is being interpretted as zero rather than not required. Now I can't see any point in coding attributes that aren't needed, but web editors do stupid things. What does the spec require in this case? In any case I should have thought that maxsize="" should be ignored since enforcing a limit of zero makes the input field useless. -- _ |_|. _ Richard Porter http://www.minijem.plus.com/ |\_||_mailto:[EMAIL PROTECTED]
Re: Forms with maxsize=""
On 5 Aug 2008 John-Mark Bell wrote: > On Tue, 5 Aug 2008, Richard Porter wrote: >> I am unable to enter data in some input fields on a form. The reason >> seems to be the attribute maxsize="". The form seems to work on >> Windoze browsers. I suspect that the null string is being interpretted >> as zero rather than not required. > Assuming you mean maxlength="", then that's fixed in SVN. Yes. According to the spec the default is an unlimited number, not zero. -- _ |_|. _ Richard Porter http://www.minijem.plus.com/ |\_||_mailto:[EMAIL PROTECTED]
Re: Forms with maxsize=""
On Tue, 5 Aug 2008, Richard Porter wrote: I am unable to enter data in some input fields on a form. The reason seems to be the attribute maxsize="". The form seems to work on Windoze browsers. I suspect that the null string is being interpretted as zero rather than not required. Assuming you mean maxlength="", then that's fixed in SVN. John.
Re: Forms with maxlength=""
On 5 Aug 2008 John-Mark Bell wrote: > On Tue, 5 Aug 2008, Richard Porter wrote: >> I am unable to enter data in some input fields on a form. The reason >> seems to be the attribute maxsize="". The form seems to work on >> Windoze browsers. I suspect that the null string is being interpretted >> as zero rather than not required. > Assuming you mean maxlength="", then that's fixed in SVN. Sorry, yes I did mean maxlength. R -- _ |_|. _ Richard Porter http://www.minijem.plus.com/ |\_||_mailto:[EMAIL PROTECTED]
