Unable to login at chase.com due to NS_ERROR_FAILURE (SeaMonkey only)

RESOLVED FIXED in seamonkey2.34

Status

SeaMonkey
General
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: mcsmurf, Assigned: mcsmurf)

Tracking

Trunk
seamonkey2.34

SeaMonkey Tracking Flags

(seamonkey2.31 wontfix, seamonkey2.32+ fixed, seamonkey2.33+ fixed, seamonkey2.34+ fixed)

Details

(Whiteboard: See Comment 21 for workaround!)

Attachments

(1 attachment, 2 obsolete attachments)

(Assignee)

Description

3 years ago
Currently one cannot login at chase.com with trunk, aurora and beta builds. When you click on the "Log In to Accounts" button, nothing happens. In the error console you see those two errors (with current comm-central build):
Error: TypeError: list is undefined
Source File: resource://gre/modules/AppsServiceChild.jsm
Line: 112

Error: NS_ERROR_FACTORY_NOT_REGISTERED: (I also saw NS_ERROR_FAILURE happen here in another build, need to check that again)
Source File: https://mfasa.chase.com/auth/js/mfp.js
Line: 4

From what I saw in a debugger, it fails here:
[7428] WARNING: Failed to get JS implementation for contract: file f:/mozilla/tree-hg/comm-beta/mozilla/dom/bindings/BindingUtils.cpp, line 2138
JavaScript error: https://mfasa.chase.com/auth/js/mfp.js, line 4: NS_ERROR_FAILURE:

static already_AddRefed
ConstructNavigatorObjectHelper(JSContext* cx, GlobalObject& global, ErrorResult& aRv)
{
  JS::Rooted jsImplObj(cx);
  nsCOMPtr window =
this part fails ---->    ConstructJSImplementation(cx, "@mozilla.org/webapps;1", global, &jsImplObj, aRv);
  if (aRv.Failed()) {
    return nullptr;
  }
  // Build the C++ implementation.
  nsRefPtr impl = new DOMApplicationsRegistry(jsImplObj, window);
  return impl.forget();
}

(note the above code is generated during build time as far as I see this, so you won't find it in the repository).
(Assignee)

Updated

3 years ago
status-seamonkey2.31: --- → affected
status-seamonkey2.32: --- → affected

Comment 1

3 years ago
Have you consulted any of the /dom/ experts?
(Assignee)

Comment 2

3 years ago
And more precisely it fails here in BindingUtils.cpp:
nsCOMPtr<nsISupports> implISupports = do_CreateInstance(aContractId);
    if (!implISupports) {
      NS_WARNING("Failed to get JS implementation for contract");
      aRv.Throw(NS_ERROR_FAILURE);
      return;
    }

with
+		aContractId	0x0a047d20 "@mozilla.org/webapps;1"	const char *
(Assignee)

Comment 3

3 years ago
So to reproduce this problem, go to the Error Console and evaluate:
Components.classes["@mozilla.org/webapps;1"].createInstance();

You will get those two errors:
Error: list is undefined
Source File: resource://gre/modules/AppsServiceChild.jsm
Line: 112

Error: NS_ERROR_XPC_CI_RETURNED_FAILURE: Component returned failure code: 0x80570015 (NS_ERROR_XPC_CI_RETURNED_FAILURE) [nsIJSCID.createInstance]
Source File: javascript:%20Components.classes["@mozilla.org/webapps;1"].createInstance();
Line: 1

The first error will only appear on the first evaluation of this piece of code, the second error every time.
(Assignee)

Comment 4

3 years ago
A workaround(?) for this seems to be: Insert this line

Components.utils.import("resource://gre/modules/Webapps.jsm");

at the top of dom/apps/AppsServiceChild.jsm, then the login seems to work. Looks like Webapps.jsm does not get loaded in SeaMonkey without this? Maybe it gets loaded in Firefox before this via http://mxr.mozilla.org/comm-central/source/mozilla/browser/modules/WebappManager.jsm#13 on startup (see nsBrowserGlue.js, which inits/loads WebappManager.js). But I'm not really familiar with how sendSyncMessage (that's the code/error from AppsServiceChild.js in Comment 3) works:
111     let list = this.cpmm.sendSyncMessage("Webapps:GetList", { })[0];
112     this.webapps = list.webapps;
(Assignee)

Comment 5

3 years ago
Created attachment 8519596 [details] [diff] [review]
Patch?

This patch seems to work and I'm not sure why.
So to me it looks like this: This code "let list = this.cpmm.sendSyncMessage("Webapps:GetList", { })[0];" returns an undefined list. According to an attached JS debugger Webapps.jsm is not even loaded at the time this code gets executed (it should be as far as I see this). Also no debug code in the init code of Webapps.jsm gets executed. See Comment 4 for why I think this works in Firefox (but not really sure about this).
(Assignee)

Updated

3 years ago
Component: General → DOM
Product: SeaMonkey → Core
(Assignee)

Comment 6

3 years ago
Created attachment 8519597 [details] [diff] [review]
Patch?

See Comment 5 for patch description.
Attachment #8519596 - Attachment is obsolete: true
(Assignee)

Updated

3 years ago
Summary: Unable to login at chase.com due to NS_ERROR_FAILURE → Unable to login at chase.com due to NS_ERROR_FAILURE (SeaMonkey only)

Comment 7

3 years ago
Comment on attachment 8519597 [details] [diff] [review]
Patch?

Can't load Webapps.jsm in child processes.
Attachment #8519597 - Flags: feedback-
(Assignee)

Comment 8

3 years ago
Neil: Do you know how to fix this? My knowledge about e10s (and related technologies) is limited atm.
Flags: needinfo?(neil)

Comment 9

3 years ago
(In reply to Frank Wein from comment #8)
> Neil: Do you know how to fix this? My knowledge about e10s (and related
> technologies) is limited atm.

IIRC Firefox loads during final UI init (BrowserGlue lazily loads WebappsManager.jsm which loads Webapps.jsm).
Flags: needinfo?(neil)
(Assignee)

Comment 10

3 years ago
Created attachment 8527843 [details] [diff] [review]
Cu.import Webapps.jsm in nsSuiteGlue.js [checked-in comment 24

This seems to work, but looks kinda strange to me...
Attachment #8519597 - Attachment is obsolete: true
(Assignee)

Comment 11

3 years ago
=> to SeaMonkey product again, although I wonder if core browser functionality should need some app-logic (Webapps.jsm) for login on a website to work?
Component: DOM → General
Product: Core → SeaMonkey
It depends.

navigator.mozApps is exposed unconditionally but implemented in JS.  So if you don't provide the JS component that implements it, doing navigator.mozApps will throw an exception.  If the site does that as part of their login JS, login could fail.

So the options are either what we have now or not exposing navigator.mozApps if the component doesn't exist.  The latter could be done pretty easily if we want to support that mode of operation.

Updated

3 years ago
Duplicate of this bug: 1107965

Updated

3 years ago
Duplicate of this bug: 1108101

Updated

3 years ago
Duplicate of this bug: 1108392

Comment 16

3 years ago
Comment on attachment 8527843 [details] [diff] [review]
Cu.import Webapps.jsm in nsSuiteGlue.js [checked-in comment 24

(In reply to Frank Wein [:mcsmurf] from comment #10)
> Created attachment 8527843 [details] [diff] [review]

> This seems to work, but looks kinda strange to me...
> +        Components.utils.import("resource://gre/modules/Webapps.jsm");

This works because Webapps.jsm inits itself:
http://mxr.mozilla.org/comm-central/source/mozilla/dom/apps/Webapps.jsm?rev=71a0e053308c#4664

> 4663 
> 4664 DOMApplicationRegistry.init();
> 4665

Alternatively package (package-manifest.in) WebappManager.jsm and reference it in nsSuiteGlue.js:

XPCOMUtils.defineLazyModuleGetter(this, "WebappManager",
                                  "resource:///modules/WebappManager.jsm");
....
      case "final-ui-startup":
....
    WebappManager.init();
Attachment #8527843 - Flags: review+

Comment 17

3 years ago
Mon Dec 08 2014 13:44:48
Error: NS_ERROR_FACTORY_NOT_REGISTERED: 
Source file: https://mfasa.chase.com/auth/js/mfp.js
Line: 4

function jsonSignature() {
	var signature = {};
	var navigatorMap = {};
	for (var prop in navigator) { // <--- This is line 4
		try {		
			var value = eval("navigator." + prop);
			if ((typeof value == 'boolean') || (typeof value == 'number') ||
				(typeof value == 'string') || (typeof value == 'array') ||
				(typeof value == 'null')) {
					navigatorMap[prop] = value;
			}
		} catch (e) {}
	}

*If* This is run:
> Components.utils.import("resource://gre/modules/Webapps.jsm");
before|navigator.mozApps;| is accessed (e.g. by mfasa.chase.com/auth/js/mfp.js)
Then I can proceed further, but without an account at Chase I'm stuck.

I've asked in Mozillazine[1] for someone with a Chase account to test my hypothesis.

[1] http://forums.mozillazine.org/viewtopic.php?p=13917113#p13917113

Updated

3 years ago
Duplicate of this bug: 1108758

Comment 19

3 years ago
(In reply to Philip Chee from comment #17)
> *If* This is run:
> > Components.utils.import("resource://gre/modules/Webapps.jsm");
> before|navigator.mozApps;| is accessed (e.g. by
> mfasa.chase.com/auth/js/mfp.js)
> Then I can proceed further, but without an account at Chase I'm stuck.
> 
> I've asked in Mozillazine[1] for someone with a Chase account to test my
> hypothesis.
> 
> [1] http://forums.mozillazine.org/viewtopic.php?p=13917113#p13917113

I have tried evaluating this line in the console:

Components.utils.import("resource://gre/modules/Webapps.jsm");

After this I am able to log into chase.com. Before that the login button
did not do anything for me. This worked fine in SeaMonkey 2.30.

Comment 20

3 years ago
(In reply to Commander from comment #19)
> (In reply to Philip Chee from comment #17)
> > *If* This is run:
> > > Components.utils.import("resource://gre/modules/Webapps.jsm");
> > before|navigator.mozApps;| is accessed (e.g. by
> > mfasa.chase.com/auth/js/mfp.js)
> > Then I can proceed further, but without an account at Chase I'm stuck.
> > 
> > I've asked in Mozillazine[1] for someone with a Chase account to test my
> > hypothesis.
> > 
> > [1] http://forums.mozillazine.org/viewtopic.php?p=13917113#p13917113
> 
> I have tried evaluating this line in the console:
> 
> Components.utils.import("resource://gre/modules/Webapps.jsm");
> 
> After this I am able to log into chase.com. Before that the login button
> did not do anything for me. This worked fine in SeaMonkey 2.30.

This worked for me as well - after evaluating the line, logon to Chase worked exactly the way it used to, up to and including "2.30.0".  -JW

Comment 21

3 years ago
(In reply to Philip Chee from comment #16)
> Comment on attachment 8527843 [details] [diff] [review]
> Sane idea?
> 
> (In reply to Frank Wein [:mcsmurf] from comment #10)
> > Created attachment 8527843 [details] [diff] [review]
> 
> > This seems to work, but looks kinda strange to me...
> > +        Components.utils.import("resource://gre/modules/Webapps.jsm");
> 
> This works because Webapps.jsm inits itself:
> http://mxr.mozilla.org/comm-central/source/mozilla/dom/apps/Webapps.
> jsm?rev=71a0e053308c#4664
> 
> > 4663 
> > 4664 DOMApplicationRegistry.init();
> > 4665
> 
> Alternatively package (package-manifest.in) WebappManager.jsm and reference
> it in nsSuiteGlue.js:
> 
> XPCOMUtils.defineLazyModuleGetter(this, "WebappManager",
>                                   "resource:///modules/WebappManager.jsm");
> ....
>       case "final-ui-startup":
> ....
>     WebappManager.init();

The steps recommended by Phillip Chee solved the problem for me, Thanks Phillip: 
1. Restart SeaMonkey. DO NOT go to chase.com YET
2. Open the Error Console (CTRL-SHIFT-J)
3. Evaluate: Components.utils.import("resource://gre/modules/Webapps.jsm");
4. Try to login to chase.com

Comment 22

3 years ago
> I've asked in Mozillazine[1] for someone with a Chase account to test my
> hypothesis.
> 
> [1] http://forums.mozillazine.org/viewtopic.php?p=13917113#p13917113

OK. Everyone that tried this says it worked. \o/
Assignee: nobody → bugzilla
Status: NEW → ASSIGNED

Updated

3 years ago
Duplicate of this bug: 1051002

Updated

3 years ago
Keywords: checkin-needed

Comment 24

3 years ago
Comment on attachment 8527843 [details] [diff] [review]
Cu.import Webapps.jsm in nsSuiteGlue.js [checked-in comment 24

Pushed to comm-central:
http://hg.mozilla.org/comm-central/rev/0e4fe8e422cc
Attachment #8527843 - Attachment description: Sane idea? → Cu.import Webapps.jsm in nsSuiteGlue.js [checked-in comment 24

Updated

3 years ago
status-seamonkey2.33: --- → affected
status-seamonkey2.34: --- → fixed
tracking-seamonkey2.32: --- → +
tracking-seamonkey2.33: --- → +
tracking-seamonkey2.34: --- → +
Target Milestone: --- → seamonkey2.34

Comment 25

3 years ago
Comment on attachment 8527843 [details] [diff] [review]
Cu.import Webapps.jsm in nsSuiteGlue.js [checked-in comment 24

[Approval Request Comment]
Regression caused by (bug #): navigator.mozApps (See comment 12)
User impact if declined: Users cannot login to Chase bank (We seem to have a lot of users who have accounts at Chase) and proably other bank login sites as well.
Testing completed (on m-c, etc.): Tested and confirmed working by users - See Mozillazine thread
Risk to taking this patch (and alternatives if risky): low to none. Bustage fix.
String changes made by this patch: None.
Attachment #8527843 - Flags: approval-comm-beta?
Attachment #8527843 - Flags: approval-comm-aurora?
(Assignee)

Updated

3 years ago
Whiteboard: See Comment 21 for workaround!
Attachment #8527843 - Flags: approval-comm-beta?
Attachment #8527843 - Flags: approval-comm-beta+
Attachment #8527843 - Flags: approval-comm-aurora?
Attachment #8527843 - Flags: approval-comm-aurora+
Comment on attachment 8527843 [details] [diff] [review]
Cu.import Webapps.jsm in nsSuiteGlue.js [checked-in comment 24

Pushed to comm-aurora:
  https://hg.mozilla.org/releases/comm-aurora/rev/24019227e07b

Pushed to comm-beta:
  https://hg.mozilla.org/releases/comm-beta/rev/d5daf6a30257

Updated

3 years ago
status-seamonkey2.31: affected → wontfix
status-seamonkey2.32: affected → fixed
status-seamonkey2.33: affected → fixed

Comment 27

3 years ago
Closing as fixed. For the proposal in Comment 12 please open a new bug somewhere in Gecko/Toolkit
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED

Updated

3 years ago
Keywords: checkin-needed

Updated

3 years ago
Duplicate of this bug: 1115713
You need to log in before you can comment on or make changes to this bug.