|
|
|
I'm waiting for mozilla to play nice first.
Looks like this has been solved in 1.19.1 (0) so I think the issue can be closed.
This is still not using the internal browser for llLoadURL calls in 1.20 RC4 when it's configured to do so in preferences, so there's still something amiss.
Second Life 1.20.4 (85828) Apr 24 2008 14:59:50 (Second Life Release Candidate) Works here: Second Life 1.19.1 (4) Apr 2 2008 11:59:37 (Second Life Release)
DOESN'T here: Second Life 1.20.4 (85828) Apr 24 2008 14:59:50 (Second Life Release Candidate) Tested with: Browsers: IE7, Firefox 3, Opera 9.27, Safari 3.1.1 Need fix! Bumped the priority to Major, because this silent change of making llLoadURL call external browser by default is very bad. I can understand that because it breaks some sites, it's not good - but come on, users can be directed by content makers to change their preferences to external browser. This can be done by content makers on their website when they detect someone hitting their webpage via SL browser. Or simply by the script that is calling llLoadURL in the first place.
Yes, it's an imperfect workaround, but it is a workaround. And if the content maker is smart enough to use llLoadURL and write their own web page, they should be smart enough to do the workaround. As is now, all other content makers are forced to accept that their customers will have to be thrown to desktop by default each time they want them to interact with a webpage. Highly undesirable. Your current fix penalizes all the other content makers whose sites work fine! Lindens, BEFORE you release v1.20 as a general release, PLEASE PLEASE either (1) Revert back to previous llLoadURL and inform all the content users that use "non-standard" sites that break with internal browsers, to inform that customers to set external browser as default... ; OR, better, (2) Implement an optional parameter in llLoadURL [,browser] as defined in description. You will still have to inform content makers whose pages don't work with the internal browser to set the parameter to 1. Others, like me, will set to 0. If you don't have time to implement the "always use internal browser" or "always use external browser" option in preferences as suggested above, then leave it till v1.21 RC. The [,browser] fix is urgent, please! This change back to the old behavior is essentially breaking my content. I switched a ton of documentation from notecards to the web in part to take advantage of the internal browser. Please give us the option to send people to the internal browser using llLoadURL.
I agree with Keiki,
I notice we can still use the internal browser by going to help in the SL client and changing the url but that is clunky. And since I want my students to have a seemless SL experience disabling the internal browser with the llLoad command is really a step backwards from an educational point of view. Also disabling the internal browser, makes web on a prim less useful than it otherwise is. I know some sites don't work with the internal browser, but I'd rather that then disabling the feature. how about adding another LSLCommand along the lines of llLoadURLClient
A dedicated command that would "always" load the URL specified, using the built in browser. Perhaps this could have different limitations than the current llLoadURL (shorter delay perhaps, or a "llRequestPermission" flag to go with it (PERMISSION_TRIGGER_BROWSER), so that once granted, a scripted object could pop open the client browser without the confirmation dialog. This would allow for the robust documentation and newsfeed applications that we all want, while at the same time allowing a more traditional approach to popping open an external browser, and protecting the end user from spam attacks. For many users who prefer to open pages in the internal browser, the forced loss of this is not good.
As Keiki notes, there is now also some amount of content that has been developed on the basis of I have to agree with most of the other people up here. Once the "Internal Web Browser" feature was added, I spent days converting my documentation for products to web based info so it can be easily updated and amended. And all of my machines have a web based configuration interface rather than a notecard interface now. Thus, everyone has to leave the game now in order to change their configurations. You can't offer up a feature, have me spend days on taking advantage of that feature and then take it away from me. If someone makes a script that links to a page that doesn't work, there is the "Open In Default Browser" button.
OR - change the llLoadURL command so that there is a "AllowPreference/Force External" option to it. +1 on the idea of adding an extra parameter to specify using the internal browser.
It seems to me that, since the person writing the script knows what URL is going to be loaded, it's up to them to make sure the site works in the internal browser. This is still an issue in 1.21.6 on a Mac. It is breaking educational content I am being asked to develop.
I'm also creating educational content that would benefit from a function that would "force" opening a website in the build-in browser. Please fix this. Thanks.
why, oh, why does it take ages to get such a simple feature realized????
this very useful request now stays for over a year on the wish list and this feature makes so much sense. it can't be that we need to wait for ages. let's see if we are able to do it in the snowglobe initiative.. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Allow internal browser to be chosen instead of external when using LoadURL
((
Other than that, I'm fully agree with your suggestions, and hope this will be implemented together with HTML on prim (or before it). It sucks having to leave SL to reach 2D web. 
No it doesn't. At least on Vista, it always opens IE, although Opera is my default browser, and it's driving me nuts.
((
Other than that, I'm fully agree with your suggestions, and hope this will be implemented together with HTML on prim (or before it). It sucks having to leave SL to reach 2D web.