"open" fails on URLs if no web browser is present (it could try wget)

[luroh]

Tested in VMware with nightly 37150 and home-brewed 37154. Both of them pure gcc2.

With a never-booted fresh build, clicking a URL in AboutSystem opens a Terminal window and downloads the URL using wget.

After the download has finished, the text 'Press any key' is displayed, but only the <Enter> key actually closes the window.

After a reboot, doing the same thing (i.e. clicking a URL in AboutSystem) does seemingly nothing except generate a short burst of CPU activity.

[luroh]

Some more observations (thanks to AnEvilYak):

Running 'top -i 1' in a terminal window, 'open' seems to be responsible for the short CPU spike.

Running 'open' manually in a terminal window works only after first boot. After a reboot, 'open' fails with:

Opening URL failed: Application could not be found
open: "http://www.freetype.org": Invalid Argument

Nightly gcc2 hybrid 37150 behaves in the same way.

Installing WebPositive in nightly gcc2 hybrid 37150 works, but only at first boot. After first reboot it stops opening the URLs in WebPositive and ProcessController just shows the short CPU spike.

'checkfs /boot' looks OK.

[luroh]

Still present in 43823.

[luroh]

Still present in 46539, gcc2. However, clicking the URLs (or running open <URL>) doesn't even work after first boot now.

[scottmc]

is this still present in recent builds?

[luroh]

Yes, still here in hrev48213, gcc2. Official gcc2h version displays the same problem if WebPositive has been uninstalled.

[pulkomandy]

Is this only if Web+ is missing? If so, this is kind of expected, if you have no set preferred app for the http url filetype. What would you expect to happen? Does it work if you install NetSurf for example?

[luroh]

Is this only if Web+ is missing?

Currently, yes. It however used to work even in pure gcc2 by having wget download the URL.

What would you expect to happen?

I would expect wget to download the URL, like in the past.

Does it work if you install NetSurf for example?

No.

[pulkomandy]

I think the best way to fix that is having wget register itself as a handler for http URLs? I don't see how this would work otherwise. If that's the case this should be moved to haikuports?