9:45 a.m.
Hi All,
Consider:
<a href="AppNameRes:Help.html">Link</a>
(Where AppNameRes is some path variable.) If I click on this link, NetSurf
presents the file as a download (with type "data") rather than rendering
the file in the browser window. Is this a bug - or am I just missing
something obvious?
I use WinSnap and have nticed that while dragging NetSurf windows around
works as expected, if re-sizing the window does not snap to the top of the
icon bar - is it possible to make this work?
Thanks,
Adam
--
Adam Richardson Carpe Diem
http://www.snowstone.org.uk/riscos/
9:57 a.m.
Hmm, I'll re-write the second sentence to actually make it legible - sorry!
I use WinSnap and have noticed that while dragging a NetSurf window
around it works as expected but if re-sizing the window it does not snap
to the top of the icon bar - is it possible to make this work?
--
Adam Richardson Carpe Diem
http://www.snowstone.org.uk/riscos/
6:11 p.m.
In message <e96a9fa44d.admin(a)snowstone.org.uk>
Adam <lists(a)snowstone.org.uk> wrote:
Consider:
<a href="AppNameRes:Help.html">Link</a>
(Where AppNameRes is some path variable.) If I click on this link, NetSurf
presents the file as a download (with type "data") rather than rendering
the file in the browser window. Is this a bug - or am I just missing
something obvious?
Unfortunately I can't reproduce this here. If I create a page with the
above, the link simply doesn't work, because it is a URL with protocol
"AppNameRes" which doesn't exist. Do you still have the page that was
causing this?
I use WinSnap and have nticed that while dragging NetSurf windows
around
works as expected, if re-sizing the window does not snap to the top of the
icon bar - is it possible to make this work?
I haven't had time to investigate this. It's probably possible.
Thanks for the reports!
James
12:18 p.m.
In message <43e560a74d.james(a)ix.strcprstskrzkrk.co.uk>
James Bursa <james(a)semichrome.net> wrote:
In message <e96a9fa44d.admin(a)snowstone.org.uk>
Adam <lists(a)snowstone.org.uk> wrote:
> Consider:
> <a href="AppNameRes:Help.html">Link</a>
>
> (Where AppNameRes is some path variable.) If I click on this link, NetSurf
> presents the file as a download (with type "data") rather than rendering
> the file in the browser window. Is this a bug - or am I just missing
> something obvious?
Unfortunately I can't reproduce this here.
Sorry, sorry. My fault. The correct example is:
<a href="file:/AppNamePath:help.html">
Adam
--
Adam Richardson Carpe Diem
http://www.snowstone.org.uk/riscos/
1:58 p.m.
In message <0c67c4a74d.admin(a)snowstone.org.uk>
Adam <lists(a)snowstone.org.uk> wrote:
In message <43e560a74d.james(a)ix.strcprstskrzkrk.co.uk>
James Bursa <james(a)semichrome.net> wrote:
>
> In message <e96a9fa44d.admin(a)snowstone.org.uk>
> Adam <lists(a)snowstone.org.uk> wrote:
>
> > Consider:
> > <a href="AppNameRes:Help.html">Link</a>
> >
> > (Where AppNameRes is some path variable.) If I click on this link,
> > NetSurf presents the file as a download (with type "data") rather
> > than rendering the file in the browser window. Is this a bug - or am
> > I just missing something obvious?
>
> Unfortunately I can't reproduce this here.
Sorry, sorry. My fault. The correct example is:
<a href="file:/AppNamePath:help.html">
Did this cause the problem I described, for you?
Adam
--
Adam Richardson Carpe Diem
http://www.snowstone.org.uk/riscos/
12:26 p.m.
On 19 Sep, Adam <lists(a)snowstone.org.uk> wrote:
In message <0c67c4a74d.admin(a)snowstone.org.uk>
Adam <lists(a)snowstone.org.uk> wrote:
>
> In message <43e560a74d.james(a)ix.strcprstskrzkrk.co.uk>
> James Bursa <james(a)semichrome.net> wrote:
>
> >
> > In message <e96a9fa44d.admin(a)snowstone.org.uk>
> > Adam <lists(a)snowstone.org.uk> wrote:
> >
> > > Consider:
> > > <a href="AppNameRes:Help.html">Link</a>
> > >
> > > (Where AppNameRes is some path variable.) If I click on this link,
> > > NetSurf presents the file as a download (with type "data")
rather
> > > than rendering the file in the browser window. Is this a bug - or am
> > > I just missing something obvious?
> >
> > Unfortunately I can't reproduce this here.
>
> Sorry, sorry. My fault. The correct example is:
> <a href="file:/AppNamePath:help.html">
Did this cause the problem I described, for you?
Anyone else?
I've just come across this problem again - clicking "Help..." on the icon
bar menu of Richard Goodwin's HTML3 produces the same result. :-(
Adam
--
Adam Richardson Carpe Diem
http://www.snowstone.org.uk/riscos/
2:06 p.m.
In message <989030b64d.admin(a)snowstone.org.uk>
Adam <lists(a)snowstone.org.uk> wrote:
[snip]
I've just come across this problem again - clicking "Help..." on the
icon bar menu of Richard Goodwin's HTML3 produces the same result. :-(
I have composed an AppBasic application that shows the problem. It has
two 'Help' menu entries.
Help Path: has NetSurf offering a save, it calls this :-
PROCLaunchURL("file:/HelpHTML:Docs/help.html")
Help <Dir> behaves as expected, it calls this :-
PROCLaunchURL("file:/<HelpHTML$Dir>/Docs/help.html")
For the demo I have borrowed the PROC from !HTML³
Source is provided.
http://www.pittdj.co.uk/temp/help.zip
I hope this helps.
--
David Pitt.
Castle Iyonix, RISC OS 5.10.
1:05 p.m.
Hi All,
Firstly, thanks for the ongoing work - I'm particularly happy with the
recent speed improvements in the URL completion list and that a page where
I use background-image now works too :-)
Secondly...
On 3 Sep, I <lists(a)snowstone.org.uk> wrote
Consider:
<a href="file:/AppNameRes:Help.html">Link</a>
(Where AppNameRes is some path variable.) If I click on this link, NetSurf
presents the file as a download (with type "data") rather than rendering
the file in the browser window.
I reported this on the bug tracker page and it has now been fixed :-)
My question is, what happens to bugs on the bug tracker page when they're
solved? I expected to find my entry in "Closed", but it's not there -
should it be?
Thanks,
Adam
--
Adam Richardson Carpe Diem
http://www.snowstone.org.uk/riscos/
1:54 p.m.
On 5 Jan, John-Mark Bell <jmb202(a)ecs.soton.ac.uk> wrote:
On Thu, 5 Jan 2006, Adam wrote:
> My question is, what happens to bugs on the bug tracker page when they're
> solved? I expected to find my entry in "Closed", but it's not there -
> should it be?
It is there - fifth item down at present.
Doh. Sorry, I missed the default option assignee=unassigned.
Adam
--
Adam Richardson Carpe Diem
http://www.snowstone.org.uk/riscos/
1:52 p.m.
On 5 Jan, I <lists(a)snowstone.org.uk> wrote:
On 3 Sep, I <lists(a)snowstone.org.uk> wrote
> Consider:
> <a href="file:/AppNameRes:Help.html">Link</a>
>
> (Where AppNameRes is some path variable.) If I click on this link, NetSurf
> presents the file as a download (with type "data") rather than rendering
> the file in the browser window.
I reported this on the bug tracker page and it has now been fixed :-)
Oh :-( I think I spoke too soon.
It seems there's still a problem. I've re-opened the bug on the bug tracker
with a fresh example app, which also shows a new(?) problem where the HTML
file wont open if NetSurf is already loaded.
Adam
--
Adam Richardson Carpe Diem
http://www.snowstone.org.uk/riscos/
2:25 p.m.
On Wed, 11 Jan 2006, Adam wrote:
It seems there's still a problem. I've re-opened the bug on
the bug tracker
with a fresh example app, which also shows a new(?) problem where the HTML
file wont open if NetSurf is already loaded.
Well, there's no new example app attached to that bug afaics. Please
attach it or send it to me (off list).
John.
2:45 p.m.
On 11 Jan, John-Mark Bell <jmb202(a)ecs.soton.ac.uk> wrote:
On Wed, 11 Jan 2006, Adam wrote:
> It seems there's still a problem. I've re-opened the bug on the bug tracker
> with a fresh example app, which also shows a new(?) problem where the HTML
> file wont open if NetSurf is already loaded.
Well, there's no new example app attached to that bug afaics. Please
attach it or send it to me (off list).
Oops, sorry. Should be there now (though I forgot to put in a
description...)
Adam
--
Adam Richardson Carpe Diem
http://www.snowstone.org.uk/riscos/
6:01 p.m.
On 11 Jan, Adam <lists(a)snowstone.org.uk> wrote:
On 11 Jan, John-Mark Bell <jmb202(a)ecs.soton.ac.uk> wrote:
>
> On Wed, 11 Jan 2006, Adam wrote:
>
> > It seems there's still a problem. I've re-opened the bug on the bug
> > tracker with a fresh example app, which also shows a new(?) problem
> > where the HTML file wont open if NetSurf is already loaded.
>
> Well, there's no new example app attached to that bug afaics. Please
> attach it or send it to me (off list).
Oops, sorry. Should be there now (though I forgot to put in a
description...)
Oh, as you say on the bug report - I mis-constructed the path, sorry! (I
guess the hard-space bug got in there and bewildered me ;-)
Anyway, the reason I'm posting here... JMB says:
"The other issue (of running an application whose !Run file is
typed to HTML) is so unlikely to occur in the real world that
I'm not inclined to fix it."
Well, fair enough - it's not a big bug! I only came across it by chance in
constructing my (unrelated) bug report. Presumably, however, the very fact
I happened across it means it's not /wildly/ unlikely - and surely it's
still a "bug", if a minor one.
Also - why does it happen? I thought double-clicking an application was the
same as Filer_Run-ing the !Run file?
Thanks,
Adam
--
Adam Richardson Carpe Diem
http://www.snowstone.org.uk/riscos/
6:58 p.m.
On Tue, 17 Jan 2006, Adam wrote:
Anyway, the reason I'm posting here... JMB says:
"The other issue (of running an application whose !Run file is
typed to HTML) is so unlikely to occur in the real world that
I'm not inclined to fix it."
Well, fair enough - it's not a big bug! I only came across it by chance in
constructing my (unrelated) bug report. Presumably, however, the very fact
I happened across it means it's not /wildly/ unlikely - and surely it's
still a "bug", if a minor one.
I didn't say it wasn't; I just said it wasn't worth fixing. As my comment
said, this situation only arises when an application's Run file is typed
as HTML and NetSurf is already running.
Also - why does it happen? I thought double-clicking an application
was the
same as Filer_Run-ing the !Run file?
Not quite. The Filer broadcasts a DataOpen message for the file
double-clicked on (so in the case of an application, it'll fill in the
message's type field with that reserved for application (&1000, iirc)). If
this then bounces, the Filer will then look for an Alias$@RunType_XXX
variable (where XXX is the type of the application's Run file). If one is
found, the Filer will issue the equivalent of *@RunType_XXX ...!App.!Run
If none is found, you get an error message informing you that the Filer
can't find an application to handle the file you clicked on.
In the case of double-clicking on the Run file, the Filer will broadcast
a DataOpen with the Run file's information contained within it. Bounce
behaviour is the same as for applications.
John.
2:19 p.m.
On 17 Jan, John-Mark Bell <jmb202(a)ecs.soton.ac.uk> wrote:
On Tue, 17 Jan 2006, Adam wrote:
> Anyway, the reason I'm posting here... JMB says:
>
> "The other issue (of running an application whose !Run file is
> typed to HTML) is so unlikely to occur in the real world that
> I'm not inclined to fix it."
>
> Well, fair enough - it's not a big bug! I only came across it by chance
> in constructing my (unrelated) bug report. Presumably, however, the
> very fact I happened across it means it's not /wildly/ unlikely - and
> surely it's still a "bug", if a minor one.
I didn't say it wasn't; I just said it wasn't worth fixing. As my comment
said, this situation only arises when an application's Run file is typed
as HTML and NetSurf is already running.
Yes, OK - but presumably the bug should be degraded to a "1" or whatever,
rather than actually closed ;-)
> Also - why does it happen? I thought double-clicking an
application was
> the same as Filer_Run-ing the !Run file?
Not quite. [snip details]
Oh, interesting. Thanks :-)
Adam
--
Adam Richardson Carpe Diem
http://www.snowstone.org.uk/riscos/
3:47 p.m.
On Mon, 23 Jan 2006, Adam wrote:
On 17 Jan, John-Mark Bell <jmb202(a)ecs.soton.ac.uk> wrote:
> On Tue, 17 Jan 2006, Adam wrote:
>
>> Anyway, the reason I'm posting here... JMB says:
>>
>> "The other issue (of running an application whose !Run file is
>> typed to HTML) is so unlikely to occur in the real world that
>> I'm not inclined to fix it."
>>
>> Well, fair enough - it's not a big bug! I only came across it by chance
>> in constructing my (unrelated) bug report. Presumably, however, the
>> very fact I happened across it means it's not /wildly/ unlikely - and
>> surely it's still a "bug", if a minor one.
>
> I didn't say it wasn't; I just said it wasn't worth fixing. As my
comment
> said, this situation only arises when an application's Run file is typed
> as HTML and NetSurf is already running.
Yes, OK - but presumably the bug should be degraded to a "1" or whatever,
rather than actually closed ;-)
Not really; the resolution would be "Won't fix" anyway ;)
John.
6343
days inactive
6485
days old
netsurf-users@netsurf-browser.org
16 comments
4 participants
participants (4)
-
Adam -
David Pitt -
James Bursa -
John-Mark Bell