New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make wrapper report its own version #4

Open
SilvanScherrer opened this Issue Jul 27, 2017 · 0 comments

Comments

Projects
None yet
1 participant
@SilvanScherrer
Contributor

SilvanScherrer commented Jul 27, 2017

Currently, the wrapper plugin (npflos2.dll) tries to mimic the real Flash plugin version information which can be seen in the about:plugins dialog.

However, the version information for mozilla plugins is stored in the resource strings inside the DLL, which means it is static and cannot be generated at runtime. This in turn means that even if you change the real flash DLL (npswf32.dll) to a different version, the wrapper will still show the version hard coded into it which will not match the actual version of Flash (the one you see when e.g. you visit ​http://kb2.adobe.com/cps/155/tn_15507.html).

This makes no sense and is misleading. It would be better to report the version of the wrapper instead.

comment by dmik
Done in r51. In r52 I changed the wrapper version number from 0.2.9999 to 0.3.1. See commits for details.

comment by abwillis
Fox and Hulu are now not seeing supported versions, Fox says it is outdated and Hulu that the device is not supported. Fox had stopped working anyhow due to some change on their site and Hulu would only play the commercials but the both saw the plugin version as OK.
I am not sure where to check what the site sees, the Adobe about site shows the 11.1 but did before this change as well.

comment by abwillis
http://playerversion.com/
http://www.codegeek.net/flash-version.php
http://www.whatismyflash.com/
Depends on how the site checks the version... the above sites show no flash installed with the new way but does detect it with the old plugin.
The adobe site:
http://www.adobe.com/software/flash/about/
Sees the actual flash version with either the new or the old plugin, as does:
http://duber.com/LetsTalk/playerCheck.html
Apparently Fox and Hulu use the first method and CBS uses the second method.

comment by diver
seems like they use this ​http://code.google.com/p/swfobject/ to get the flash version

comment by dmik
Yes, indeed, these first three links use the swfobject.js script to detect Flash version. The script logic is seriously wrong as it parses the plugin's file description (!) field in order to detect its version (although there are separate product name and version fields whih obviously fit the purpose much better). It will get broken once Adobe decides to change the description string in a new version of the plugin (why not)... Too bad it is already so widely distributed, we'll have to support it.

In r53, I reverted the description string to the contents it had before ("Shockwave Flash 10.0 r45") and this makes all the scripts happy. The rest of the new code is left intact, i.e. it will report the actual wrapper version in the Version field.

We may want to update this string to contain "11.x" later when we make the 11.x series of the plugin work with it.

BTW, this field is static now (read by Mozilla from the DLL resource). It would be much better to make it dynamic so that it could transparently report the description field from the real Win32 plugin. Probably the simplest way of doing that is to patch Mozilla so that it calls a special export in the plugin DLL to get the dynamic description instead of reading it from the resource.

comment by diver
we should consider to add the special export (as explained above), when we port latest ffox.

comment by diver
should we do that at all with our Firefox?

comment by dmik
We actually still want this since it's better to report the actual Win32 Flash plugin version (through the file description string) since (as shown above) there may be some scripts that depend on the version number so it is safer to make it match the reality.

It's not difficult at all, all required functionality is there. On the wrapper side it will require to export the NP_GetValue callback which is used on Linux to get the plugin file description string as well as reading of the Win32 version information (which is already done in r125).

However, since this also requires modifications in the code (to make use of NP_GetValue on OS/2) of Firefox which we have just released, I have to postpone completing this task till the next Firefox release (will happen quite soon).

comment by dmik
Created a Firefox issue for that: ​bitwiseworks/mozilla-os2#49.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment