Old version of flash 4.x is used even when 6.x has the latest version installed

VERIFIED FIXED in mozilla0.9.7

Status

()

P1
normal
VERIFIED FIXED
17 years ago
15 years ago

People

(Reporter: shrir, Assigned: peterl-bugs)

Tracking

Trunk
mozilla0.9.7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
Ok..seen on 1212 trunk win NT.

steps:
1 Close existing browsers completely
2 Copy the attached files to your 4.x plugins folder and restart 4.x
3 Now, with 6.x recommended install/custom, you should get the flash 5.0r41 
  version installed automatically.
4 Just, launch 6.x build and load the page above
5 Do a right click and see that "About Flash Player 4..." is listed at the 
  bottom ..which is wrong.

ALSO, after step 5, if you do an "about :plugins" in the 6.x window, you will 
see that flash 5.x is listed. Now revisit the page above and right click...
see that the correct plugin (5.x) is listed. Plugin refresh works.
(Reporter)

Comment 1

17 years ago
Created attachment 61782 [details]
4.0 flash for 4.x plugins folder

Comment 2

17 years ago
something like this happens in bug 114026
(Reporter)

Comment 3

17 years ago
*** Bug 114026 has been marked as a duplicate of this bug. ***

Comment 4

17 years ago
Created attachment 61829 [details] [diff] [review]
possible fix?

Here is a possible fix, but it's not the only way to fix this. By flipping the
internal linked list of plugins in reverse order after scanning is complete,
you'll notice that about:plugins now lists plugins in scan order (as apposed to
reverse like it is now). This means that whatever mimetype is seen FIRST (in
about:plugins) wins in a conflict situation. So, Flash 5 in the application
folder will win against Flash 4 in the 4.x folder as long as the application
folder is scanned first (which it is). I think this is the desired effect.

Comment 5

17 years ago
     I have this same problem; the Mozilla 0.96 does not have this problem, but
current builds do.  I build from source, but I have downloaded one or two recent
builds (last week or so) and they acted the same way.  
     But, if you look at the flash 5 plugin, the text"About Macromedia Flash
Player 5..." and "About Flash Player 4..." *both* are in the binary.  So, I
don't know what triggers the "Movie not Loaded"/"About Flash Player 4..."
behavior but it isn't due to an older version of flash being loaded.  (I'd
already looked for old plugins laying around, and don't believe I have any.)

Comment 6

17 years ago
Comment on attachment 61829 [details] [diff] [review]
possible fix?

r=av. This will also bring more pleasant user experience. Good to have untill
we implement more poweful plugin management tool.
Attachment #61829 - Flags: review+

Comment 7

17 years ago
OK, I'm slapping all the nomination keywords on this since I think this is an
important fix for users of the embedding branch(es) to benefit from.
Keywords: edt0.9.4, mozilla0.9.7, nsbranch

Comment 8

17 years ago
Patrick, what do you think of this patch?
Assignee: av → peterl
Keywords: patch, review
OS: Windows NT → All
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → mozilla0.9.7

Comment 9

17 years ago
FYI, I applied the patch and so far don't see any abnormalities.

Comment 10

17 years ago
When we scan multiple directories, which directories do we scan first? 
Reversing this list will change that ordering as well. Perhaps we should 
instead change the code which builds the list to always append to the list 
rather than "pushing" on to the head of the list. You just need a head and 
tail pointer for that. If that's too much work, then, sure, I'll go along with 
this. Your choice.

Comment 11

17 years ago
Comment on attachment 61829 [details] [diff] [review]
possible fix?

sr=beard
Attachment #61829 - Flags: superreview+

Comment 12

17 years ago
Here's the order we scan:

1) XPCOM (through registry)
2) application plugins directory list from the directory service (bin, embedding)
3) os locations (OSX Internet-Plugins)
4) 4.x (selective)
5) JRE (optional)

The code for making the plugin/mime-type match just traverses the linked list so
since we are adding to the front of the list during scanning, we may get the
wrong plugin during usage.

I thought about adding a tail pointer but there is more than one place we add
and remove nodes and this approach of flipping the stack seemed simpler.
Status: NEW → ASSIGNED
Keywords: review

Comment 13

17 years ago
we do want this on the branch, but, let's bake it on the trunk for a couple of days.

Comment 14

17 years ago
in trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 15

17 years ago
a=asa (on behalf of drivers) for checkin to 0.9.7
Keywords: mozilla0.9.7 → mozilla0.9.7+

Comment 16

17 years ago
fixed0.9.7
Keywords: fixed0.9.7

Comment 17

17 years ago
Will plus for 094 once verified on trunk/097.
(Reporter)

Comment 18

17 years ago
verif on trunk 1221 win/mac/linux. I don't see any problem with this testcase 
and other plugins as well. 

Comment 19

17 years ago
Plus ing for 094 since fix verified on trunk
Keywords: edt0.9.4 → edt0.9.4+

Comment 20

17 years ago
fixed0.9.4
Keywords: patch → fixed0.9.4
(Reporter)

Comment 21

17 years ago
fixed on 0101 branch 0.9.4 as well. VERIF.
Status: RESOLVED → VERIFIED
(Reporter)

Comment 22

17 years ago
had already verifid these bugs on 0.9.4 branch..adding keyword 'verified0.9.4'.
Keywords: verified0.9.4, verified0.9.7

Updated

15 years ago
Keywords: fixed0.9.4

Updated

15 years ago
Keywords: fixed0.9.7
You need to log in before you can comment on or make changes to this bug.