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/
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
Could the sub/superscript inversion be related to the fact that
NetSurf currently shows Awstats histograms upside down?
This bug (either base line or vertical orientation wrong
for inline graphics) was cured way back, but seems to have crept back in.
Gavin Wraith (gavin(a)wra1th.plus.com)
Home page: http://www.wra1th.plus.com/
Has anyone else notices that NetSurf, the RISC OS version at least,
displays subscript text as superscript?
I've submitted a bug report, ID 2037940, but at least I'd like to
know whether others have observed the same.
Here's a test you can use:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<body bgcolor = "#FFFFFF" text = "#000000" link = "#3366CC">
<p align="left"><h1>Test page </h1>
<p align = "left">Subscript: CO<sub><small>2</small></sub></p>
<p align = "left">Superscript: CO<sup><small>2</small></sup></p>
<p align = "left">Full size subscript: CO<sub>2</sub></p>
No - Not the Carpenters !
It's Sunday and my History shows only 'Last Week' and 'Today'
Next time some work is done on the History routines could you
arrange for 'Yesterday' to always exist.
This is not a major problem, it only happens on Sundays when the
current week's daily histories are consolidated, but it would be
useful if I want to go back to yesterday's (Saturday) browsing.
Keep up the good work, I can see from the high rate of release numbers
that there is a lot of background development going on.
- Thank you all.
|)ryn [vans mail to - BrynEvans(a)bryork.freeuk.com
On Wed, 30 Jul 2008, Jess Hampshire wrote:
> In message <20080729112922.37ac9cee(a)trite.i.flarn.net.i.flarn.net>
> Rob Kendrick <rjek(a)netsurf-browser.org> wrote:
>> Please do not email us log files from crashed sessions of NetSurf with
>> zero context. We did not request the log, as suggested in your
>> subject line, nor any of the previous dozen. It is not helpful in the
> I suspect that is his (reasonable) interpretation of the error box.
>> least, and wastes our and your time. Please either use the bug tracker,
>> or report issues on this mailing list. You may be requested to send us
>> the log file /after/ you have done this.
> Perhaps you could replace the error message with something as clear as
> this posting?
Clearly Rob's posting wasn't clear enough, seeing as you've missed the
point of it :)
The issue is not that bugs are being reported -- we're very grateful for
that. It is, instead, that a Log file on its own does not constitute a
bug report. There are many things the Log file can tell us, but a
description of the exact things the user was doing when the fault occurred
can often be equally, if not more, useful.
The bug tracker, despite its faults, does at least result in some context
being given. So far, the bugs@ mail alias has not (even when we've replied
to mails sent to that address asking for context). Therefore, we've shut
it down until such time as a better solution is forthcoming.