Closed
Bug 457068
Opened 17 years ago
Closed 14 years ago
DigitalMe and other add-ons fail due to removal of eval's second argument in bug 442333
Categories
(Firefox :: Extension Compatibility, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: ignisvulpis, Unassigned)
References
Details
(Keywords: regression, Whiteboard: every URL when one of the extensions (openinfocard, DigitalMe, CardSpace4Firefox) is installed )
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.2) Gecko/2008091620 Firefox/3.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.2) Gecko/2008091620 Firefox/3.0.2
I guess that this eval( ..., doc) here
http://code.google.com/p/openinfocard/source/browse/trunk/firefox/chrome/infocard/content/InformationCard.js#802
does not work anymore. It worked from Firefox 1.5 to 3.0.1. After the update to 3.0.2 the variable doc.__identityselector__ is undefined after the runInterceptScript function ran. It was set by this function in previous version.
Reproducible: Always
Steps to Reproduce:
1. Install one of the extensions from
1a) http://code.google.com/p/openinfocard/downloads/list or
1.b) http://www.codeplex.com/IdentitySelector/Release/ProjectReleases.aspx?ReleaseId=14914#ReleaseFiles
1.c) http://code.bandit-project.org/downloads/DigitalMe/firefox/digitalme-xpi-0.4.2217.xpi
2. Open any web page
2a) http://informationcard.net/wiki/index.php/Browser_Integration_WG
3.
Actual Results:
Depending on which extension is installed different error-alert are displayed.
Openinfocard alerts that each webpage contains information card object but that there is a problem. This is due to doc.__identityselector__ not beeing initialized by the runInterceptScript.
Expected Results:
No alert.
Pages without information card specifig objects are observed but not modified or acted upon.
http://ignisvulpis.blogspot.com/2008/09/firefox-302-breaks-id-selector-browser.html
Comment 1•17 years ago
|
||
Same issue described above to be reported for platform Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.2) Gecko/2008091618 Firefox/3.0.2
Digitalme extension for Firefox at http://code.bandit-project.org/downloads/DigitalMe/firefox/digitalme-xpi-0.4.2217.xpi worked until Firefox upgraded from 3.0.1 to 3.0.2.
Comment 2•17 years ago
|
||
There were changes made to eval that might have broken that sort of behaviour, however I believe that that was in Firefox 3.0. Is this something that definately broke between 3.0.1 and 3.0.2?
Keywords: qawanted
Comment 3•17 years ago
|
||
Yes. This is something that happened between 3.0.1 and 3.0.2. I was testing iCard support no latter than this morning. It broke with the 3.0.2 upgrade. I am positive on that.
Comment 4•17 years ago
|
||
Yes, it's bug 442333's fix that caused this (in order to close a scope-traversal leak). evalInSandbox should be used by extension code as a substitute, if I understand the outcome of that bug correctly.
Updated•17 years ago
|
Updated•17 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•17 years ago
|
Flags: blocking1.9.0.4?
Reporter | ||
Comment 5•17 years ago
|
||
Using evalInSandbox instead of eval(..., doc) is not working. doc is an HTMLDocument. With the sandbox-code I get the error message "ReferenceError: document is not defined".
I tried this:
try {
var sandbox = new Components.utils.Sandbox(doc.defaultView);
Components.utils.evalInSandbox(
" document.__identityselector__ = new Object();" +
" document.__identityselector__.data = new Object();" +
" document.__identityselector__.submitIntercepted = false;" +
" document.__identityselector__.chainSubmit = " +
" HTMLFormElement.prototype.submit;" +
" HTMLFormElement.prototype.submit = function()" +
" {" +
" var event = document.createEvent( 'Event');" +
" event.initEvent( 'ICFormSubmit', true, true);" +
" this.dispatchEvent( event);" +
" document.__identityselector__.chainSubmit.apply( this);" +
" };" +
" document.__identityselector__.valueGetter = function()" +
" {" +
" var event = document.createEvent( 'Event');" +
" event.initEvent( 'ICGetTokenValue', true, true);" +
" this.dispatchEvent( event);" +
" return( this.__value);" +
" };"
, sandbox);
} catch(e) {
IdentitySelector.logMessage("runInterceptScript:exception", e);
alert( e);
}
The 3.0.1 working code was:
eval(
"try" +
"{" +
" document.__identityselector__ = new Object();" +
" document.__identityselector__.data = new Object();" +
" document.__identityselector__.submitIntercepted = false;" +
" document.__identityselector__.chainSubmit = " +
" HTMLFormElement.prototype.submit;" +
" HTMLFormElement.prototype.submit = function()" +
" {" +
" var event = document.createEvent( 'Event');" +
" event.initEvent( 'ICFormSubmit', true, true);" +
" this.dispatchEvent( event);" +
" document.__identityselector__.chainSubmit.apply( this);" +
" };" +
" document.__identityselector__.valueGetter = function()" +
" {" +
" var event = document.createEvent( 'Event');" +
" event.initEvent( 'ICGetTokenValue', true, true);" +
" this.dispatchEvent( event);" +
" return( this.__value);" +
" };" +
"}" +
"catch( e)" +
"{" +
" alert( e);" +
"}", doc);
The context for this is here:
http://code.google.com/p/openinfocard/source/browse/trunk/firefox/chrome/infocard/content/InformationCard.js#802
I could move the lines that define the __identityselector__ object outside the eval (replacing document with doc). But we originally introduced the eval(...,doc) because defining the HTMLFormElement.prototype.submit and document.__identityselector__.valueGetter did not work without the eval.
-- related for the extension but probably unrelated to this bug?...>>
Yesterday I experimented with adding an observer for earlyformsubmit to catch the form submit from extension-code. But, yes I got the event but from the event handler I can not modify the forms content because the submission data is collected before the observer is notified through SubmitSubmission... This is no way to make the extensions work again...
Anyways the most important thing for our Identity Selector extensions to work again with FF 3.0.3 is to make the getter to work again.
The html object of type application/x-informationcard is part of a form. When the form is submitted the value of the object should be retrieved by the getter. The getter starts the Information Card selector xul-GUI.
Any ideas how to define the getter for html-objects in extension code?
Did this (getter or form-control-value-getting) change in 3.0.2 too?
<<--
Comment 6•17 years ago
|
||
Shouldn't be:
try {
var sandbox = new Components.utils.Sandbox(doc.defaultView);
sandbox.document = doc;
Components.utils.evalInSandbox(
...
Comment 7•17 years ago
|
||
(In reply to comment #5)
I'm confused as to why the block of code immediately above what you link to,
located here:
http://code.google.com/p/openinfocard/source/browse/trunk/firefox/chrome/infocard/content/InformationCard.js#773
is commented out (and, as you alluded to, not working). What are the specific
errors that you're getting? (as that should be a valid solution to the problem
that you're having)
Reporter | ||
Comment 8•17 years ago
|
||
(in reply to <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=457068#c7">comment #7</a>)
Lines 775,776,777,776 work. The functions don't work - I believe - because doc is not defined when the function is/are called. I must admit that this part of the code is not originally written by me and that therefore I am sometimes confused myself what works and what might be a leftover part from experiments but never worked.
The code in InformationCard.js as it currently is (r490) in the openinfocard code repository works with 3.0.1 but not with 3.0.2. The 3.0.1-eval function seems to define document to have the value of doc and even the functions are scoped so that document == doc when they are called later.
Reporter | ||
Comment 9•17 years ago
|
||
(in reply to comment #6)
yes that helped a little. This changes the error message to:
IdentitySelector:runInterceptScript:exception: ReferenceError: HTMLFormElement is not defined
Adding
sandbox.HTMLFormElement = HTMLFormElement;
yields:
[Exception... "Security Manager vetoed action" nsresult: "0x80570027 (NS_ERROR_XPC_SECURITY_MANAGER_VETO)" location: "JS frame :: chrome://infocard/content/InformationCard.js :: <TOP_LEVEL> :: line 852" data: no]
Hm... I split the statements.
Which leads to:
[Exception... "Security Manager vetoed action" nsresult: "0x80570027 (NS_ERROR_XPC_SECURITY_MANAGER_VETO)" location: "JS frame :: chrome://infocard/content/InformationCard.js :: <TOP_LEVEL> :: line 844" data: no]
Line 844 is this:
Components.utils.evalInSandbox(
" document.__identityselector__.chainSubmit = " +
" HTMLFormElement.prototype.submit;" +
" HTMLFormElement.prototype.submit = function()" +
" {" +
" var event = document.createEvent( 'Event');" +
" event.initEvent( 'ICFormSubmit', true, true);" +
" this.dispatchEvent( event);" +
" document.__identityselector__.chainSubmit.apply( this);" +
" };"
, sandbox);
Suggestion?! Thanks.
Comment 10•17 years ago
|
||
Seeing same problem. 3.0.1 -> 3.0.2 blew out DigitalMe. Fails with PamelaWare, but perhaps others as well. A good test site is http://www.identityblog.com.
1. Install DigitalMe
2. Go to above web site and attempt to log in with an Information Card.
3. Presto. Error as described in Comment #1.
Reporter | ||
Comment 11•17 years ago
|
||
A new version of DigitalMe was just released
http://code.bandit-project.org/downloads/DigitalMe/firefox/digitalme-xpi-0.5.2480.xpi
Andrew Hodgkinson of Novell circumvents the problem by using "@mozilla.org/moz/jssubscript-loader;1":
http://code.bandit-project.org/trac/browser/trunk/digitalme/launchers/firefox-addon/xul/chrome/content/IdentitySelector.js#L461
The script that is loaded is here:
http://code.bandit-project.org/trac/browser/trunk/digitalme/launchers/firefox-addon/xul/chrome/content/Intercept.js
Users report that this fixes the problem up to version 3.0.3 of Firefox.
What is the Mozilla way to change the HTMLFormElement.prototype.submit scoped to a specific document? Using "@mozilla.org/moz/jssubscript-loader;1" does not look "right" to me.
Comment 12•17 years ago
|
||
With the new DigitalMe, WFM.
Updated•17 years ago
|
Summary: If one of the extension is installed there are problems with every web page, because the extensions install a DOMcontentloaded handler → DigitalMe and other add-ons fail due to removal of eval's second argument in bug 442333
Updated•17 years ago
|
Whiteboard: every URL when one of the extensions (openinfocard, DigitalMe, CardSpace4Firefox) is installed
Comment 13•17 years ago
|
||
Here's a list of potential other addons that might be broken because of the change, though it's unlikely given that we haven't heard other feedback from others.
https://addons.mozilla.org/en-US/firefox/addon/5723 (WebAii Automation
Infrastructure - Firefox Client)
https://addons.mozilla.org/en-US/firefox/addon/1729 (Execute JS)
https://addons.mozilla.org/en-US/firefox/addon/5165 (Firebug Japanese)
https://addons.mozilla.org/en-US/firefox/addon/2516 (Mnenhy)
https://addons.mozilla.org/en-US/firefox/addon/216 (Venkman)
https://addons.mozilla.org/en-US/firefox/addon/3871 (Fingerfox)
https://addons.mozilla.org/en-US/firefox/addon/5678 (Qworum)
https://addons.mozilla.org/en-US/firefox/addon/8487 (Pencil)
https://addons.mozilla.org/en-US/firefox/addon/6357 (UxU - UnitTest.XUL)
https://addons.mozilla.org/en-US/firefox/addon/5373 (Thunderbrowse)
https://addons.mozilla.org/en-US/firefox/addon/6590 (ThumbsDown)
https://addons.mozilla.org/en-US/firefox/addon/7635 (Tv Program)
--
With that said, I'm minusing this for blocking status for 1.9.0.4. If we determine that we need to fix this, we'll cycle back around, but for now we're going to leave it unfixed and rely on the extension authors to update their extensions, pending further information.
This bug, ultimately, should be WONTFIXed.
Flags: blocking1.9.0.4? → blocking1.9.0.4-
Reporter | ||
Comment 14•17 years ago
|
||
(in reply to comment #13)
Neither
http://code.bandit-project.org/trac/wiki/DigitalMe DigitalMe, nor
http://code.google.com/p/openinfocard/ openinfocard, nor
http://www.codeplex.com/IdentitySelector IdentitySelector (CardSpace for Firefox)
is on addons.mozilla.org
Have you contacted the authors from your list of add-ons? Maybe they are trying to fix this without having noticed this bug? Maybe the eval(,) is in a seldomly used part of the add-on and the bug still unnoticed in the add-ons?
I say: When eval(,) is used in this many add-ons then there seems to be a use for it.
Please recommend an alternative that works in add-ons before removing eval(,).
The alternative should not only work but be "clean".
Reporter | ||
Comment 15•17 years ago
|
||
I edited
https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Functions/eval
today.
BTW: the alternative to eval(,) stated in that wiki page did not work for me in my extension (openinfocard). When I replaced "eval(..., doc)" with
"with (doc) {
eval(...);
}" that did not work.
Comment 16•17 years ago
|
||
Is this improved or resolved by the landing of bug 446026?
Comment 17•16 years ago
|
||
When I install the openinfocard add-on, and try it on 3.0.x, I get some error messages similar to the ones described in first comment. On 3.5.7 an Identity Selector window is launched and I get options to create a new card, disable, delete card and cancel.
This never landed in 3.0.x.
Keywords: qawanted
Reporter | ||
Comment 18•16 years ago
|
||
The current version of openinfocard does not use eval(x,y) any more.
http://code.google.com/p/openinfocard/downloads/list
So this bug is now irrelevant to openinfocard.
Comment 19•14 years ago
|
||
Can we resolve this bug now? I think so. Since this bug's Version is "3.0 Branch" I am resolving WONTFIX (for that branch -- obviously we have a code fix in later releases and openinfocard worked around).
/be
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•