Closed Bug 295950 Opened 20 years ago Closed 19 years ago

UMO displays extensions that are not compatible based on the app.extensions.version pref

Categories

(addons.mozilla.org Graveyard :: Administration, defect)

Product:
addons.mozilla.org Graveyard
Component:
Administration
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: mgueury, Assigned: Bugzilla-alanjstrBugs)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Hello,

I wrote this extension: 
> Html Validator (based on Tidy) 0.6.0

That you can download here:
> http://users.skynet.be/mgueury/mozilla/download.html

The extension is one of the only one to have a XPCOM C library. 
Due to that, I have several issues in the upgrade.

First, I am unable to make an extension working for 1.0 and 1.0+.
So, I have 2 xpi files. This is because of the problem 1.

Problem 1 : Some internal mozilla functions changed of place
-------------------------------------------------------------
A) I am currently unable to make a version that works for Firefox 1.0
   and 1.1.
  If I enable 
   - the maxversion in install.rdf to 1.0+ 
   - with the C library 1.0
   when the extension is loaded in Firefox 1.0+, it gives this error message
   when loading firefox. Because the function nsMemory::clone is not anymore
   in the xpcom.dll
  
   XPCOM:EventReceiver The procedure entry point 
   ?Clone@nsMemory@@SAPAXBXI@Z could not be found in the dynamic 
   library xpcom.dll

-> The solution is to :
   1. have 2 XPI files, one for 1.0 and one for 1.0+. (This lead to problem 3)
   2. set maxversion to 1.0. (This leads to problem 2.)
-> The advantage it works.

Problem 2 - The extension disappears in the list of Firefox 1.0+
----------------------------------------------------------------
So, minversion=0.8 maxversion=1.0 in my 1.0 extension. 
And minversion=1.0+ maxversion=1.0+ in my 1.1 extension. 

If I install the extension 1.0 in Firefox 1.0, then start Firefox 1.0+
-> The extension is not anymore in the extension list and and the user 
   does not see that the extension is disabled.

Testcase problem 2 (for Windows)
--------------------------------
- start firefox 1.0. Install the extension for 1.0.
  http://htmlvalidator.sourceforge.net/mozilla/tidy_firefox_win_060.xpi
- stop/start firefox 1.0. Check the the extension works.
- start firefox 1.0+. Look the extension list. The extension is not listed.

Problem 3 - 2 XPI files, one for 1.0 and one for 1.0+
-----------------------------------------------------
I have the same extension for Firefox 1.0 and 1.0+ with the 
same version number, same GUID. So, practically 2 XPI. I am really 
afraid that if I upload the 1.0+ version, that the 1.0 version will be 
overwritten and that a lot of people will have issues of installation.

-> The ideal solution is that update.mozilla.org detect the firefox 
   version number. And propose the good extension depending of the user 
   version.

Reproducible: Always

Steps to Reproduce:
See above

Actual Results:  
-

Expected Results:  
-

-
Problem 4 - workign with 2 version on my PC
-------------------------------------------
This is the opposite issue than the problem 1. (functions changed of library)
To test this, I have Firefox 1.0.4 and 1.0+ on my machine.
minversion=0.8 maxversion=1.0 in my 1.0 extension. 
minversion=1.0+ maxversion=1.0+ in my 1.1 extension. 

If I install the 1.0+ version in 1.0+ it works. But when starting the 1.0.4
afterwards, I get this error message: 

XPCOM:EventReceiver:firefox.exe - Entry Point Not Found
The procedure entry point NS_Alloc could not be located in the dynamic library
xpcom.dll

Testcase problem 4 (for Windows)
--------------------------------
- start firefox 1.0+. Install the extension for 1.0+.
  http://htmlvalidator.sourceforge.net/mozilla/tidy_firefox_11_win_060.xpi
- stop/start firefox 1.0+. Check the the extension works.
- start firefox 1.0. 
  -> Error: The procedure entry point NS_Alloc
-> this should not happens: the minversion is 1.0+

Thanks by advance,
Summary: Problem with upgrade to 1.1 with extensions containing native C library → Problem with upgrade to 1.1 with extensions containing native C library
please only one issue/bug. (I tend to mark this bug invalid based on that)

problem 1) seems invalid because you seem to used unfrozen interfaces.
problem 2) should be bug 292619
morphing this bug for problem 3 only -> Software Update
problem 4 should be ignored in this bug report. Please report a new bug.
Also note that this can't be fixed in FF1.0.X, only for future release builds.
Assignee: nobody → Bugzilla-alanjstrBugs
Component: Extension/Theme Manager → Administration
Product: Firefox → Update
QA Contact: extension.manager → mozilla.update
You need different version numbers if you want both XPIs hosted on UMO.  You can
use 1.0.x for your <= 1.0 "branch" and 1.1.x for your >= 1.0+ branch.
Hi Alan,

Can you confirm that this is correct ?

So, minversion=0.8 maxversion=1.0 in my 1.0 extension. 
And minversion=1.0+ maxversion=1.0+ in my 1.1 extension. 

If yes, I upload new version of the extension to UMO.

Thanks.

Ps: I will log other bugs for Problem 1/3. But they are a lot less important.
Yes, that looks right.  
The only solution to problem 1 when using unfrozen interfaces is to have
seperate packages for each version it is compatible with or only use frozen
interfaces.

Problem 2 was fixed by the patch in bug 293419 and it will be instaled and disabled.

I believe problem 3 was answered by Alan though I don't know if there are
remaining issues.

For problem 4 if the extension has the correct compatibility info (e.g. the one
that is not compatible with 1.0.4 has a minVersion of 1.0+) it should be
disabled when you launch 1.0.4 in your example.

Are there any remaining issues?
Hello

Problem 1 : I logged bug 297318
Problem 2 : duplicate of bug 293419
Problem 3 : 
 - The file name in UMO are based on extension_name + platform + version ext.
 - So, I uploaded a version 0.60 for Firefox 1.0 (min:0.8, max:1.0)
 - So, I uploaded a version 0.61 for Firefox 1.1 beta (min:1.0+, max:1.0+)
   only Linux for testing.

 The extension are not yet accepted. But I am sure it will work.

Problem 4:
 - I should log a new bug. Even with the good info in maxversion, minversion
   it still happens. I suppose that the version test is badly done.

 

If you file a new bug for problem 4 could you please attach simple extension
testcases? See bug 252418 for a couple of testcase samples. I happened to try
this inadvertently last night and the EM disabled an extension with a minVersion
and maxVersion of 1.1 which is correct and I have previously tested a minVersion
and maxVersion of 1.0 with a recent build and it was also disabled. Perhaps the
issue you are seeing with problem 4 is with 1.0.4 since it WFM with a recent trunk?
I just increased the priority of this bug.

I did this only for Linux. 
- uploaded a version 0.60 for Firefox 1.0 of my extension to UMO.
  - minversion=0.8, maxversion=1.0
  -> ok
- uploaded a version 0.60 for Firefox 1.1 of my extension to UMO.
  - minversion=1.0+, maxversion=1.0+
  -> it did not work since a combination of extension_name/platform/version
     already existed.
  
So, I work-arounded this by:
- uploaded a version 0.61 for Firefox 1.1 of my extension to UMO.
  It was the same file but with the version changed.
  - minversion=1.0+, maxversion=1.0+
  -> the upload was ok, extension approved.

Now, when I use Firefox 1.04 on Linux.
- go to UMO
- developer tools
- HTML validator extension
  -> problem 1: the link in the list is empty, the size too ?
  -> problem 2: In firefox 1.0, I see the 0.61 extension for Firefox 1.1 !!
                Even if I see well valid for 1.0+ to 1.0+ 
     The expected behavior was to see the version 0.60
   
  -> If I install it I will have the problem 4 described above:
     - Error: The procedure entry point NS_Alloc
       When starting firefox on Windows ( or a coredump on Linux )
  
Thanks by advance

(I will leave it the file there so that you see it)
Severity: normal → major
I did a second similar test. 
- on Windows, the only uploaded version is 0.60 for Firefox 1.0
   minversion=0.8, maxversion=1.0

If I use Firefox 1.1 beta. 
- When going to UMO, 
- Developer tools
- I see the version 0.60 (with a right maxversion/minversion)
  What will cause me the problem 2 if I install it.

Thanks by advance

Per your first test see comment #3 - you MUST have different version numbers for
each version as I think you went on to do in the second test. It isn't a work
around - it is the way it is suppose to work. The version number is one of the
ways it is able to key into a specific version and this specific version will
have specific app compatibility info.

If you install an extension that has its compatibility info properly set it
should not install if it is not compatible per this info. If it does that would
be an EM install bug and I don't believe you have experienced this per your
comments. So, the statement of "If I install it I will have the problem 4
described above" should not occur if you have followed the specifications in
regards to setting your app compatibility info for each version.

Seeing an extension that is not compatible with the version you are running on
UMO is a bug but it is not an EM install bug.

So, this bug seems to be about showing the proper version of an extension on
UMO... true?
Hi Robert,

Yes, completely true. I wish to keep this problem for the UMO problem only.

For the extension installation problem, I have logged bug 297318.
But I would need to log another one for the problem 4. I will try to do it 
asap.

Thanks
(In reply to comment #12)
> But I would need to log another one for the problem 4. I will try to do it 
> asap.
When you do file a bug for problem 4 please provide steps and testcases as
stated in comment #8 - so far, I haven't been able to reproduce that problem.

Thanks
Forgot to ask if you could also update the summary? Thanks
For problem 4, I logged bug 297665 with a testcase step-by-step and links to 
the XPIs.

Changed the title of this bug to reflect that it handles only problem 3.

Thanks
Summary: Problem with upgrade to 1.1 with extensions containing native C library → UMO does not detect the firefox extension and could propose imcompatible extensions
tweaked summary a bit more
Summary: UMO does not detect the firefox extension and could propose imcompatible extensions → UMO displays extensions that are not compatible based on the app.extensions.version pref
UMO has no access to that preference.
If you have difficulties to detect it automatically, you could do in another
way. For example, show the 2 versions in a list next to the extensions like:

For Firefox 0.8 to 1.0 - Version 0.60 
For Firefox 1.1 - Version 0.61

I checked the user agent given by Firefox 1.0.4:

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8)
Gecko/20050511 Firefox/1.0.4

It can be used to autodetect the version.
We used to autodetect the UA.  But the squid proxy caching was problematic.  Now
that caching is fixed, we might be able to bring that back.
The problem is solved for me.
Finally due to some very good trick given in bug 297665, I was able to make
an extension with a XPCOM lib that work with Firefox 1.0 and 1.1.

All of this due to another way to link !
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.