Palemoon 19.0-x64: Wrong appinfo.version Topic is solved

Talk about code development, features, specific bugs, enhancements, patches, and similar things.
Forum rules
Please keep everything here strictly on-topic.
This board is meant for Pale Moon source code development related subjects only like code snippets, patches, specific bugs, git, the repositories, etc.

This is not for tech support! Please do not post tech support questions in the "Development" board!
Please make sure not to use this board for support questions. Please post issues with specific websites, extensions, etc. in the relevant boards for those topics.

Please keep things on-topic as this forum will be used for reference for Pale Moon development. Expect topics that aren't relevant as such to be moved or deleted.
nmaier

Palemoon 19.0-x64: Wrong appinfo.version

Unread post by nmaier » 2013-02-23, 17:43

Hi,

I'm the developer of the DownThemAll! add-on. One of our common users reported this:
DTA! 3.0b3 not compatible with Pale Moon 19.0 (x64)

However, actually Pale Moon 19.0-x64 is to blame.

Code: Select all

> Components.utils.import("resource://gre/modules/Services.jsm", {}).Services.appinfo.version
< 19.0-x64
It should be 19.0, however. The extension manager will use whatever is in appinfo.version and compare that to the minVersion of the XPI to be installed.
http://mxr.mozilla.org/mozilla-release/ ... r.jsm#5550
http://mxr.mozilla.org/mozilla-release/ ... r.jsm#5594

In this case:

Code: Select all

> Components.utils.import("resource://gre/modules/Services.jsm", {}).Services.vc.compare("19.0-x64" /* pm */, "19.0" /* minVersion */) >= 0
< false
Correct would be:

Code: Select all

> Components.utils.import("resource://gre/modules/Services.jsm", {}).Services.vc.compare("19.0" /* corrected pm */, "19.0" /* minVersion */) >= 0
< true
Please note that the version comparator is not to blame. It is true to the spec.

STR: Expected:
  • Successful installation

tuxman

Re: Palemoon 19.0-x64: Wrong appinfo.version

Unread post by tuxman » 2013-02-23, 20:11

For the records: I'm the reporter of the mentioned bug (their spam checker does not let me answer there anymore, bah :mrgreen: ), so I am available here to test fixes. :)
Last edited by tuxman on 2013-02-23, 20:12, edited 1 time in total.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35478
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Palemoon 19.0-x64: Wrong appinfo.version

Unread post by Moonchild » 2013-02-23, 20:12

This is actually something that is a quirk I found with the language packs as well, when creating them.

The problem is that in the version comparison in the add-on manager, "19.0-x64" is smaller than "19.0" So the add-on's "minVersion" should be "19.0-x64" and not "19.0" for it to work on 19.0 and above, including x64.

This rings illogical but this is the way the logic works in version comparisons in the Mozilla code (a-b is smaller than a in a mathematical sense). Pale Moon follows the Mozilla spec.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

tuxman

Re: Palemoon 19.0-x64: Wrong appinfo.version

Unread post by tuxman » 2013-02-23, 20:40

Firebug recognizes Pale Moon correctly BTW.

nmaier

Re: Palemoon 19.0-x64: Wrong appinfo.version

Unread post by nmaier » 2013-02-23, 21:38

Moonchild wrote: The problem is that in the version comparison in the add-on manager, "19.0-x64" is smaller than "19.0" So the add-on's "minVersion" should be "19.0-x64" and not "19.0" for it to work on 19.0 and above, including x64.

This rings illogical but this is the way the logic works in version comparisons in the Mozilla code (a-b is smaller than a in a mathematical sense). Pale Moon follows the Mozilla spec.
Pale Moon does not alter the version comparator, that's right. In that sense it follows the spec.
The reason for the "illogical" logic is btw to enable pre-releases so that the following holds true: "19.0-x64" < "19.0a" < "19.0b" < "19.0"
Granted, it is a mess.

"19.0-x64" however does not follow any good practices... actually I consider the version string to be outright wrong. Pale Moon abuses the pre-release (string-b, number-c) parts of the version string to indicate the x64 version. This also impacts the UA, adding a redundant -x64.
It basically parses as ("19", None, 0, None, None), (0, "-x", 64, None, None). Indicating it is a "-x" pre-release of version 19.0, and the 64th at that.
So, oops, the Pale Moon string indicates Pale Moon is less of a version than Firefox 19 ALPHA/BETA versions. I'm not going to drop the minVersion of my add-on to that.
From my point of view DownThemAll! supports Firefox 19.0 and later, and Pale Moon choose not to be compatible with that. Which is fine by me, of course.
tuxman wrote:Firebug recognizes Pale Moon correctly BTW.
It does not.
First of all neither DownThemAll! nor Firebug recognize anything themselves. It is the add-on manager, part of the core product (Firefox, Pale Moon) that does the compatibility matching.
And secondly Firebug stable happens to use a minVersion of 17.0: "17.0" < "19.0-x64" < "19.0"
Once Firebug devs decide to go with a minVersion of 19.0 (likely Firebug 1.13 or even 1.12), Pale Moon x64 will reject this as well.

tuxman

Re: Palemoon 19.0-x64: Wrong appinfo.version

Unread post by tuxman » 2013-02-23, 22:07

Uhm OK, now arrange please. The DTA guys say it's Pale Moon's fault, Moonchild says it's not.

I (as a user) have to suffer from that?

edit: Ah. Postings appearing out of nowhere. Weird.
I use Firebug Alpha, not stable; having a minVersion of Firefox 18. Granted, my fault. (And yes, as an add-on dev - OpenDownload² - I know that "Firebug recognizes..." is not technically correct. But from a user's POV...)

nmaier

Re: Palemoon 19.0-x64: Wrong appinfo.version

Unread post by nmaier » 2013-02-24, 02:54

tuxman wrote:Uhm OK, now arrange please. The DTA guys say it's Pale Moon's fault, Moonchild says it's not.

I (as a user) have to suffer from that?

edit: Ah. Postings appearing out of nowhere. Weird.
I use Firebug Alpha, not stable; having a minVersion of Firefox 18. Granted, my fault. (And yes, as an add-on dev - OpenDownload² - I know that "Firebug recognizes..." is not technically correct. But from a user's POV...)
Yeah, appears that I'm too new on this board, so that my posts need approval before being displayed. Edit: Hurray, not moderated any longer!

I get that from a users POV this sucks and it doesn't matter much which piece of which software is to blame.
If there was a simple and *reliable* fix that DownThemAll! could take, I would take it. There is not, however!

Using a minVersion of 19.0-x64 would be wrong, as this would enable Firefox 19.0a and 19.0b builds as well (Nightly, Aurora, Beta), and that is unacceptable as there are technical reasons not to allow at least the a-builds, as these do not have some important fixes that make DTA work correctly. For the same reasons DTA won't support Firefox 17ESR.
I also have no desire to hack up my own installation logic to accept -x64 but not a/b just to accomodate PM x64 (read: No desire to enter maintenance hell).

Actually, I was entertaining the idea to use minVersion 20.0 - first one to support per-window private browsing mode - at some point, but decided against that in particular to accommodate Pale Moon users. As it stands right now, Pale Moon 19.0 x64 users will be left behind either way because of the bogus version string the x64 version uses. The x86 (32-bit) version does not use a bogus version string appendix and therefore is fine, though.

BTW, that -x64 appendix is a deliberate change to the mozilla source code our host Moonchild made. It has no merit whatsoever and could be easily reversed in the next Pale Moon point release. That is not my decision to make, obviously, but I can only advocate to do so as it will restore compatibility not only with DTA but any add-on using a minVersion of 19.

nmaier

Re: Palemoon 19.0-x64: Wrong appinfo.version

Unread post by nmaier » 2013-02-24, 02:59

Actually, thinking about it, the problem will likely go away with the next point release anyway:
"19.0-x64" < "19.0b" < "19.0" < "19.0.1-x64" < "19.0.1"

Still, Moonchild should keep this situation in mind for future major releases.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35478
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Palemoon 19.0-x64: Wrong appinfo.version

Unread post by Moonchild » 2013-02-24, 09:40

Yes, it will be fixed with the point release.

And it's indeed something to keep in mind, but there is very little I can do about it unless I remove the hyphen from version indicators, which I'd rather not do. 19.0.x64 looks ugly and is incorrect (it's not a point version following 19.0).
nmaier wrote:"19.0-x64" < "19.0b" < "19.0" < "19.0.1-x64" < "19.0.1"
Yes, this looks about right for the logic in place, although I'm not sure how a/b is handled. Not my favorite choice, they'd have been better off doing a string comparison instead of mathematical one...

EDIT: Unfortunately, in case you wonder why this is difficult: changing version numbers for specific parts will break things internally. It's the way the Mozilla code base is programmed, the version information has to match exactly between different components.
"Maintenance hell" is nothing compared to having to hunt down all locations in the entire source tree and make specific amends for the locations where the version string of the application matters. For example, If the version string is changed you have to completely clobber the build and rebuild it from scratch or you have a browser with many parts broken.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

jumba

Re: Palemoon 19.0-x64: Wrong appinfo.version

Unread post by jumba » 2013-02-24, 11:26

So, is there anything that users can do currently to install the DTA! 3.0b3 on PM 19 x64? Or do we have to wait for the next point release?

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35478
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Palemoon 19.0-x64: Wrong appinfo.version

Unread post by Moonchild » 2013-02-24, 11:41

You can edit the install.rdf of DTA to have a minVersion of "19.0-x64" instead of "19.0"

@nmaier: Just a quick question, would using an appinfo.version of "19.0.0-x64" have avoided this problem? Because that would be easy enough to do next time there is a new major release.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

jumba

Re: Palemoon 19.0-x64: Wrong appinfo.version

Unread post by jumba » 2013-02-24, 12:29

I get warning "This add-on could not be installed because it appears to be corrupt." after changing the <em:minVersion>19.0</em:minVersion> to <em:minVersion>19.0-x64</em:minVersion>.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35478
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Palemoon 19.0-x64: Wrong appinfo.version

Unread post by Moonchild » 2013-02-24, 13:24

Heh, I guess it's signed then, preventing any edits to the .xpi.

Anyway, Pale Moon 19.0.1 is out now, that should fix this issue.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

tuxman

Re: Palemoon 19.0-x64: Wrong appinfo.version

Unread post by tuxman » 2013-02-24, 13:32

Tested and proven working. (The "restartless add-on" needed a restart though.) :)

jumba

Re: Palemoon 19.0-x64: Wrong appinfo.version

Unread post by jumba » 2013-02-24, 16:42

I got it installed too, it was restartless for me at least.

Thanks Moonchild for the quick point release! :thumbup:

tuxman

Re: Palemoon 19.0-x64: Wrong appinfo.version

Unread post by tuxman » 2013-02-24, 16:46

Did you have version 2 installed? I did (even with one paused download), maybe this is why the update needed a restart. :)

jumba

Re: Palemoon 19.0-x64: Wrong appinfo.version

Unread post by jumba » 2013-02-24, 19:45

tuxman wrote:Did you have version 2 installed? I did (even with one paused download), maybe this is why the update needed a restart. :)
No, I did a clean install. :)

It must be for that reason because uninstalling an addon needs also restart if it is not restartless, and that's what it needed to do before upgrading to the new version, I think.

tuxman

Re: Palemoon 19.0-x64: Wrong appinfo.version

Unread post by tuxman » 2013-02-24, 23:04

Ah, OK. That may be why. :) Thank you.

nmaier

Re: Palemoon 19.0-x64: Wrong appinfo.version

Unread post by nmaier » 2013-02-25, 00:07

Moonchild wrote:Yes, it will be fixed with the point release.

And it's indeed something to keep in mind, but there is very little I can do about it unless I remove the hyphen from version indicators, which I'd rather not do. 19.0.x64 looks ugly and is incorrect (it's not a point version following 19.0).
You changed the version number in the first place, which is a bad idea. Just leave it be ;)
Let me repeat the important point: There is no need or merit in patching the version number. There are only downsides.
What is wrong with "19.0" instead of "19.0-x64" or "19.0.x64"?

BTW: One of these downsides:

Code: Select all

 246        <pluginItem  blockID="p176">
  247 -                  <match name="filename" exp="(NPSWF32\.dll)|(Flash\ Player\.plugin)" />                                    <versionRange  minVersion="10.3" maxVersion="10.3.183.18.999" severity="0" vulnerabilitystatus="1">
  248 +                  <match name="filename" exp="(NPSWF32\.dll)|(Flash\ Player\.plugin)" />                                    <versionRange  minVersion="0" maxVersion="10.3.183.18.999" severity="0" vulnerabilitystatus="1">
  249                                  <targetApplication  id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}">
  250 -                              <versionRange  minVersion="20.0a1" maxVersion="*" />
  251 +                              <versionRange  minVersion="19.0a1" maxVersion="*" />
  252                            </targetApplication>
  253                    </versionRange>
  254                    </pluginItem>
Yeah, block that in 19.0a1 and later already... But not in PM x64 as 19.0-x64 < 19.0a1
Moonchild wrote:
nmaier wrote:"19.0-x64" < "19.0b" < "19.0" < "19.0.1-x64" < "19.0.1"
Yes, this looks about right for the logic in place, although I'm not sure how a/b is handled. Not my favorite choice, they'd have been better off doing a string comparison instead of mathematical one...
There is no special handling for a/b. The algo is like this:
Blocks are delimited by a ".".
Parse each block into:
<number-a><string-b><number-c><string-d> (<string-rest>)
numbers will default to 0. strings will default to "".
numbers are compared numerically, strings using strcmp basically.

"0", "" -> (0, "", 0, "")
"19" -> (19, "", 0, "")
"19.0a1" -> (19, "", 0, ""), (0, "a", 1, "")
"19.0-x64 -> (19, "", 0, ""), (0, "-x", 64, "")

When comparing two versions, and one version has more blocks than the other one, fill the other one with blocks (0, "", 0, "")
Pseudo cmp algo:

Code: Select all

for each block:
  if v1.numA < v2.numA:
    return -1
  if v1.numA > v2.numA:
    return 1
  if strcmp(v1.strB, v2.strB) < 0:
    return -1
  if strcmp(v1.strB, v2.strB) < 0:
    return -1
  ... numC ... strD
return 0
So there is actually a lot of strcmp going on ;)

And here is the reason plain string comparison is a bad idea:

Code: Select all

#include <stdlib.h>
#include <stdio.h>
#include <memory.h>

const char* vec[] = {
  "", "a", "a", "", "a", "a", "a", "b", "b", "a", "1", "19", "19", "1", "9", "19", "19", "9", 0
};

int main() {
  for (const char **v = vec; *v; v += 2) {
    int rv = strcmp(*v, *(v+1));
    const char* rs = rv < 0 ? "first" : (rv > 0 ? "second" : "same");
    printf("[%s] [%s] smaller: %s\n", *v, *(v+1), rs);
  }
  return 0;
}

$ cc -o test test.c && ./test
[] [a] smaller: first
[a] [] smaller: second
[a] [a] smaller: same
[a] [b] smaller: first
[b] [a] smaller: second
[1] [19] smaller: first
[19] [1] smaller: second
[9] [19] smaller: second
[19] [9] smaller: first
Look at the last two lines: oops ;)
Moonchild wrote: EDIT: Unfortunately, in case you wonder why this is difficult: changing version numbers for specific parts will break things internally. It's the way the Mozilla code base is programmed, the version information has to match exactly between different components.
"Maintenance hell" is nothing compared to having to hunt down all locations in the entire source tree and make specific amends for the locations where the version string of the application matters. For example, If the version string is changed you have to completely clobber the build and rebuild it from scratch or you have a browser with many parts broken.
There are basically only four places where the version is defined:
  1. /xpcom/components/Module.h: mozilla::Module::kVersion is just the major version for binary compatiblity e.g. 19, but not 19.0.
  2. /browser/config/version.txt: This one you patches, leading to you also patching update URLs and stuff as yet another downside.
  3. /config/milestone.txt, /js/src/config/milestone.txt: Gecko, JS engine milestones (versions)
There simply is no need to "hunt down all locations in the entire source tree" as there is only a single location you patched in the first place.
Any other "hunting" is a result of the ill-advised version patching.
Moonchild wrote: @nmaier: Just a quick question, would using an appinfo.version of "19.0.0-x64" have avoided this problem? Because that would be easy enough to do next time there is a new major release.
Just try it out ;) I gave you a code snippet:

Code: Select all

Components.utils.import("resource://gre/modules/Services.jsm", {}).Services.vc.compare("19.0-x64" /* pm */, "19.0" /* minVersion */)
Run that in a chrome-enabled Web Console or Scratchpad. To enable chrome open e.g. about:config or about:memory

Still changing the version string is a bad idea in the first place!

nmaier

Re: Palemoon 19.0-x64: Wrong appinfo.version

Unread post by nmaier » 2013-02-25, 00:12

Moonchild wrote:Heh, I guess it's signed then, preventing any edits to the .xpi.

Anyway, Pale Moon 19.0.1 is out now, that should fix this issue.
Yep, signed, but you always can throw away the signature files to make it unsigned again ;)

Locked