Firefox Integration (Browser Front-End)
26/12/2017 10:19
Jon Ripley wrote: [snip] A small change needs to be made to the !Firefox.!Run file if you are receiving the message: 'Cannot open <Obey$Dir>.stderr for I/O redirection' Change the last line of the !Firefox.!Run file to: <Obey$Dir>.firefox-bin %*0 >null: 2>null: This should fix the problem but be aware that !Firefox will no longer save crash information inside !Firefox.stderr.

Please keep a copy of the original !Run file so that you can restore it if you need to report crash information.

Thanks, Jon Ripley -- http://jonripley.com/

Source is Usenet: comp.sys.acorn.apps
Sign in to add a comment

Answer score: 5
26/12/2017 10:19 - JP. Baker wrote: The shared_profiles.html page has been very helpful, I am hesitant to add workarounds for many of these as they are non-trivial and there is a much better solution that may be possible. Thanks to the links you posted I have a much better understanding of the issues I am facing running multiple instances.

I made some good progress with the cache issue thanks to your help. My cache was corrupt and all instances of Firefox were using memory caches exclusively. Deleting the corrupted caches restored the intended functionality. I want this to be mooted in the next release.

Currently the method I am exploring is to patch the binary to use alternate cache files - this is not ideal but is better than nothing for the moment. However, if it is possible to detect whether an existing disk cache is corrupt I can delete it when Firefox is not running therefore forcing Firefox to create a clean cache. But when it is practical to have only one instance running the profile corruption issues become almost moot.

On the Mozilla project site there is information about a remote control utility and API that would be of great benefit for developing the further RISC OS integration of Firefox, and, which should completely remove the need for multiple instances to be run under normal circumstances.

The remote control API includes the ability to instruct a current instance of Firefox to: o Prompt user for file/URL in a dialog box o Open a file/URL/blank in current window o Open a file/URL/blank in new window o Open a file/URL/blank in new tab http://www.mozilla.org/unix/remote.html Aside from speeding up Firefox use considerably and making the interface a lot more functional this should also allow search plugins to be used directly from the front-end without the need to rewrite the search plugin interface from scratch.

If the remote control API was available it seems that it would need to be available either as a separate utility or as a Firefox extension that provides a hook that I can call - Wimp_SendMessage would be a convenient conduit. It is, unfortunately, beyond my ability at the moment to write a Firefox extension to provide this or to port the remote utility to RISC OS.

If you or anyone out there is able to get remote working it would make an absolutely wonderful addition to Firefox Integration.

Comments? Thanks, Jon Ripley -- http://jonripley.com/

Source is Usenet: comp.sys.acorn.apps
Sign in to add a comment

Answer score: 5
26/12/2017 10:19 - JP. Baker wrote: I have a working solution to prevent cache corruption. Is this a feature that you feel it would be beneficial to implement for the main release of Firefox Integration? I have never seen cache corruption in action.

I need to look into this some more as it may be possible to work around some of the other issues but it is a major task, especially as compatibility with all beta present and future releases of Firefox need to be considered.

Comments? Jon Ripley -- http://jonripley.com/

Source is Usenet: comp.sys.acorn.apps
Sign in to add a comment

Answer score: 5
26/12/2017 10:19 - In article <XHxAe.24785$O22.7353@fe1.news.blueyonder.co.uk>, Jon Ripley <news@jonripley.com> wrote: As I said, it is sharing a profile that is the problem, AFAIK the semaphore file .parentlook is meant to stop this happening.

https://bugzilla.mozilla.org/show_bug.cgi?id=76431 https://bugzilla.mozilla.org/show_bug.cgi?id=135137 http://www.mozilla.org/projects/embedding/shared_profiles.html https://bugzilla.mozilla.org/show_bug.cgi?id=135061 John -- John P Baker

Source is Usenet: comp.sys.acorn.apps
Sign in to add a comment

Answer score: 5
26/12/2017 10:19 - In article <svtAe.24462$O22.19379@fe1.news.blueyonder.co.uk>, Jon Ripley <news@jonripley.com> wrote: This is unlikely to be safe. The message implies that there is already a copy of Firefox running and under no circumstances should you allow a second copy. In fact, the restriction should be that you should not have two copies of Firefox running using the same profile [1] but, at this stage of development, this is much the same thing.

This was an obvious shortcoming with the original source of Firefox Integration, I am assuming that it hasn't been addressed in some other way.

John [1] The problem is that there are many files in the profile that need to be in step with their in-memory counterparts - you may have already read of some problems with a corrupt form database. Of special note is the disk cache which stands an extremely good chance of breaking.

-- John P Baker

Source is Usenet: comp.sys.acorn.apps
Sign in to add a comment

Answer score: 5
26/12/2017 10:19 - JP. Baker wrote: Changing the line of the !Firefox.!Run file that runs the application has absolutely no bearing on any percieved safety issues. The changes made are to pass a parameter to firefox-bin and to prevent STDERR being multiply piped to a single file. This completely fixes a minor issue that is experienced by a minority of users with specific configurations. Even when the previous !Run file is in place the only issue is requiring to 'press SPACE or click a mouse button to continue' occasionally.

It is totally safe. Completely and utterly.

Command line parameters are read and understood by firefox-bin, passing a URL to firefox is implemented, working and I have not encountered any issues whatsoever. Also no issues have been reported to be re parameter passing by any of the people currently using Firefox Integration.

If a user wishes to run multiple copies of any application they should be allowed to. There is nothing I can see in the Firefox documentation which states that only one instantiation should ever be active at a time.

I would prefer not to run multiple instantiations of Firefox purely for memory and system overhead reasons. Firefox in its current state is perfectly capable of having multiple windows open. However I have as yet not been able to determine any way to ask firefox to open a new window or a new tab and load a specific URL. If you know of a way that would make this possible I will incoropoprate it and render this whole issue moot.

I have been using the RISC OS port Firefox since the first beta was released. In that time I have had multiple instantiations of Firefox loaded, active and in use. At no time have I encountered any issues that would imply that this was a bad idea. In fact, Firefox seems very happy with the arrangement.

Not one user of Firefox Integration has ever reported any problems with running multiple instantiations of Firefox - aside from the very minor issue above.

I have been following Firefox related discussions on usenet and I do not recall seeing anything that would indicate that there would be any problems whatsoever.

In addition I use Firefox on a number of other platforms and frequently have multiple active instantiations all using the same profile and have never had any problems whatsoever.

I don't entirely see how. But if it could be proved to me somehow that there were pertinant and reproducable issues with this arrangement that appears to be working without any problems whatsoever then please contact me privately and I will investigate the matter.

You have not contacted me privately to tell me of any possible issues that may or may not exist in my software or its interaction with Firefox. I would prefer in future that if you have any serious misgivings about any of my software that you contect me privately by email and not in a public forum.

My original post was made to assist users of the software.

Grrr, Jon Ripley -- http://jonripley.com/

Source is Usenet: comp.sys.acorn.apps
Sign in to add a comment

Answer score: 5
26/12/2017 10:19 - Jon Ripley <news@jonripley.com> wrote: [snip] I'm a little behind the current progress on ChoX11, but the above seems to suggest the remote control API is implemented with X properties. These aren't present in ChoX11 AFAIK but a quick look at the sources you mentioned suggest it might be possible to have ChoX11 translate Wimp messages into X property events. Some hacking on ChoX11 is required here - but at first cursory glance I don't see any fundamental problems...

Theo

Source is Usenet: comp.sys.acorn.apps
Sign in to add a comment

Answer score: 5
26/12/2017 10:19 - In article <xwdCe.50026$O22.42323@fe1.news.blueyonder.co.uk>, Jon Ripley <news@jonripley.com> wrote: It looks as if the cache is safe as the first instance holds the files open and so subsequent instances almost certainly run with only a memory cache as they cannot open them.

Use about:cache to see if it has two sections, memory and disk, or just memory.

Anyone who has ever had a Firefox crash is likely to already have a corrupted disk cache and to be just running on the memory cache anyway.

The only solution to this seems to be to delete all the cache files and start afresh.

Some of the other files in the profile may be a problem but most of those appear to be forgetting actions (prefs, cookies), as mentioned in the shared_profiles.html page, so may just cause unexpected behaviour.

It is a shame that the Linux builds can't emulate the Windows builds and convert a new instance into a new window in the existing instance.

I have half a feeling that there may be some way of avoiding multiple copies with an extension - something that polls [1] or responds to events and then opens required URL in new window or tab - I am pretty sure that extensions can include native C code but even javascript may be enough - but I haven't had time to look too closely yet and, of course, extensions and security are still in a state of flux as holes are exposed.

[1] even a pipe may be good enough John -- John P Baker

Source is Usenet: comp.sys.acorn.apps
Sign in to add a comment

eDiscover
Helpforce eDiscover provides technical articles updated each dayHelpforce eDiscover RSS feed contains the latest technical articles in RSS
Click the logo to go back to the main page
Search eDiscover
  
Categories

Click an icon to go to that category

Helpforce eDiscover contains articles about Microsoft Windows Helpforce eDiscover contains articles about Apple products and MacOS Helpforce eDiscover contains articles about Linux and POSIX operating systems Helpforce eDiscover contains articles about Helpforce Helpforce has a large variety of technical information and articles for you to read Helpforce eDiscover contains articles about databases, MYSQL, SQL Server Oracle Helpforce eDiscover contains articles about Java, JVM and the JRE Helpforce eDiscover contains articles about the QNX operating system Helpforce eDiscover contains articles about Oracle Solaris and Open Solaris Helpforce eDiscover contains articles about RISC OS, Acorn and the BBC Micro Helpforce eDiscover contains articles about Amiga and AmigaOS

Type your comment into the box below