Nope its definatly not Firefox 3.6.3. Continuing to track it down further now.

Ok it looks like this http://hg.mozilla.org/releases/mozil...e/32e8189050ad is the closest revision in the mozilla tree to microb-engine_20100401-1.9.2.orig.

Doing a diff of that revision against microb-engine reveals that its a 100% match except that mozilla-1.9.2 has the following files microb-engine does not have:
build/pgo/js-input/string-base64.html
js/src/tests/e4x/Regress/regress-319872.js
js/src/tests/js1_5/Function/regress-338001.js
js/src/tests/js1_5/Function/regress-338121-01.js
js/src/tests/js1_5/Function/regress-338121-02.js
js/src/tests/js1_5/Function/regress-338121-03.js
js/src/tests/js1_5/Regress/regress-303213.js
js/src/tests/js1_5/String/regress-314890.js
js/src/tests/js1_5/String/regress-322772.js
js/src/tests/js1_5/extensions/regress-336409-1.js
js/src/tests/js1_5/extensions/regress-336409-2.js
js/src/tests/js1_5/extensions/regress-336410-1.js
js/src/tests/js1_5/extensions/regress-336410-2.js
js/src/tests/js1_5/extensions/regress-342960.js
js/src/trace-test/tests/basic/testBug507425.js
layout/style/crashtests/432561-1.html
toolkit/crashreporter/google-breakpad/src/processor/testdata/minidump2.dmp

My guess (based on checking the revision history of those files on the tip of both mozilla-central and mozilla-1.9.2) is that what we have in microb-engine is 32e8189050ad revision minus those files for some reason (possibly they were removed because they triggered anti-virus software somewhere or otherwise failed some internal Nokia something)

The date of that commit (Mar 31 2010) also fits with the dates we see in the filenames and in the changelog.

About the only way we could get any closer to where it all came from is if we could find Andrey Petrov (listed in the changelog as the one doing the relavent commits) and get info from him (if he still has any)

Thank you!
32e8189050ad translates to 1.9.2.3pre, 20100401035720:
ftp://ftp.mozilla.org/pub/mozilla.or...mozilla-1.9.2/

Best wishes.
~~~~~~~~~~~~~~~~~
Per aspera ad astra...

in the changelog there is mention of sync wsith 1.9.2 except 2/3 commits. could be related to those files.

Andrey has a Linkedin page but I have no clue if that helps us contact him or if he would be of any help if we were able to contact him.

Perhaps try twitter first ?
https://twitter.com/shazow

allthough, he doesnt seem too active there

According to linked in he's now at intel?
A little digging and I've found https://github.com/android-ia/platfo...773fab446e87b1 signed off by possibly the same Andrey, with email.

Would romaxa have any more info?

I have done some analysis and the only changes to npapi between microb-engine and current tip that matter to use are these 2 bugs
https://bugzilla.mozilla.org/show_bug.cgi?id=906072
https://bugzilla.mozilla.org/show_bug.cgi?id=653201
One removes entries in npapi.h, the other removes the backend code that supported it.

I can confirm that Flash is using this feature and also tablet-browser-default-plugin I think uses it. So we need to bring it back in an ABI compatible way somehow if we want plugin compatibility.

Ok, going through all the plugins/extensions shipped with a standard Fremantle install:
The solution for adobe-flashplayer is to somehow re-implement that npapi function in the post above. This will also solve all the problems for tablet-browser-mediaplayer-plugin and tablet-browser-default-plugin and allow them to work as-is.
For libssoautologin, we need to figure out just what it is for and whether keeping it working matters. And if it does, we will likely need to clone it so it can be made to work with the newer Gecko version (finding all the Gecko interfaces it uses and ensuring those are still ABI compatible is an exercise in futility given that interfaces are no longer frozen in Gecko)
maemo-geolocation is open source so we can port that.

That just leaves Nokia Maps. We can A.Drop support for it completly (not good given that people like me use it), B.Clone the whole thing and port it to the new Gecko (not really an option given that npatlas.so is over 4mb in size AND makes a lot of calls to the Gecko APIs), C.Find a new maps app that is just as good as Nokia Maps (including the nice offline caching and storage stuff) or D.Find a way to have maps use the old Gecko and everything else using the new Gecko. This should be possible given that maps is the only thing talking to Gecko directly (via browser-eal) instead of going through browserd. So we would replace browserd with a new one that talks to the new Gecko version but we keep the old Gecko version around (including browser-eal) for maps.

But Ovi Maps can't download maps anymore... Maybe we could put the old gecko somewhere else and edit the nokia maps code (it's html) to use the new location?

Or we might temporarily drop Ovi Maps and when we have working Gecko decide what to do with it.