Add-ons For PaleMoon

[IDEVFH]

Hi,

I've created a new add-on that will work with PaleMoon.

Is it appropriate to ask for beta tester here on this forum ?

Regards,
IDEVFH

[Blacklab]

I've created a new add-on that will work with PaleMoon.

Welcome! Assuming you are the developer of Memory Fox 7.4 Add-on and not some trolling impostor! I've had a very quick look at your homepage: http://idevfh.com/ today but didn't see a "new Add-on" mentioned? Could you please explain the nature/purpose of your new Add-on?

EDITS: Can't spell this morning - it's impostor not imposter - anyhow l hope you are the real thing!

[Moonchild]

I'm sure Pale Moon users here will be happy to help Definitely appropriate to ask for beta testing on this forum.

I suggest you make a new topic with a clear title and description of the add-on, links to the add-on to be tested, and instructions on what to test and what feedback you are looking for, then have people give their feedback in replies on that thread.
If you need any help with the forum side of things (e.g. the original post has to be edited past the normal editing time, or similar) send me a PM and I'll help you out.

[IDEVFH]

Hi Moonchild,

I sent you a PM about the addon with a link. Let me know if you need any additional information.

p.s. In my PM I failed to mention that I've not release to Mozilla AMO editors the add-on. I wanted to make sure all testing was well with it using PaleMoon also.

Regards,
IDEVFH

[Moonchild]

I've had a look at the Add-on's description... It's not safe to have Pale Moon use the IPC plugin system and then removing access to the plugin container on-the-fly. It will break the browser's internals and you'll get a ton of asserts as a result. It's a rather ugly hack that I really don't recommend - you should redesign your add-on to actually replace the plugin container with a functional stub instead of just removing it, to prevent internal errors.

You might want to have a look at the source for the plugin container .exe in the Pale Moon/Firefox source tree and keep all functions in place, but remove the actual plugin loading part, and compile a stub from that.

[IDEVFH]

Thank you for the check with this addon against PaleMoon. I'll take your suggestion and check back here. I appreciate the time you've taken Moonchild !

edit: What I do intend to do is take some of the code from this add-on and apply it to release the pages in the virtual set that are residing in the physical memory and apply it in a different add-on for PaleMoon for on-demand usage.
This action will not have any negative results. Microsoft states that transitional pages will be kept cached in Ram.

Update edit: Moonchild, I found the section I need to call in the plugin source code that will probably do the job succinctly calling the d-tors normally to unload the plugin. Thank you again for pointing me in that direction.

Regards,
IDEVFH

[IDEVFH]

nsPluginHost.cpp

// We have some options for unloading plugins if they have no instances.
//
// Unloading plugins immediately can be bad - some plugins retain state
// between instances even when there are none. This is largely limited to
// going from one page to another, so state is retained without an instance
// for only a very short period of time. In order to allow this to work
// we don't unload plugins immediately by default. This is supported
// via a hidden user pref though.
//
// Another reason not to unload immediately is that loading is expensive,
// and it is better to leave popular plugins loaded.
//
// Our default behavior is to try to unload a plugin three minutes after
// its last instance is destroyed. This seems like a reasonable compromise
// that allows us to reclaim memory while allowing short state retention
// and avoid perf hits for loading popular plugins.

Rethinking:
As said above, I've determined that even though it would be easily
implemented, the removal of a plugin in the plugin-container. It would
be a BAD solutions to what I'm desiring to achieve for reducing ram
memory usage.

Conclusion:
What will be safe is to deactivate plugin play ( NOT ) remove, follow by a
flushing of the plugin of it's virtual paging since the pages now have become
orphaned in memory. This is the approach I've now have implemented.

Kudos:
It's good for a developer to have other developer eyes on a particular feature
to implement which could cause HARM to the over-all performance and usage
of an application. Thanks again, Moonchild !

Regards,
IDEVFH

[Moonchild]

Sounds a lot better to flip the state to disabled, indeed. That way you don't have to do dangerous file operations and the browser internals will remain intact by keeping access to to the plugin container; It will, as a bonus, also allow you to selectively disable some plugins, while keeping others active. A win-win.