382075 - View Selection Source triggers error in nsLoginManager.js

Status: RESOLVED DUPLICATE of bug 639092

(Toolkit :: View Source, defect)

Description

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070525 Minefield/3.0a5pre ID:2007052515 [cairo]

repro:
Open FF
select some text on a page
rightclick and select "View Selection source" from the context menu

result:
Error: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIRequest.name]
Source file: file:///C:/Programmas/FF30/firefox/components/nsLoginManager.js
Line: 315

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Sounds like we're catching loads we shouldn't be.

Comment 2

[Justin Dolske [:Dolske]]

Yeah, it's due to these lines in nsLoginMananger.js's onStateChange()...

 311             // Only process things which might have HTML forms.
 312             if (! domDoc instanceof Ci.nsIDOMHTMLDocument)
 313                 return 0;

I had actually tightened that check before, but switched back to this (which is what the old code did) after some discussions as to the right way to filter things.

The immediate fix is to tweak log() entry a few lines below this which accidently generates the error, but we should also probably take another look at how to filter better.

Comment 3

[Justin Dolske [:Dolske]]

The log() line generating the error is:

    this._pwmgr.log("onStateChange accepted: req = " + (aRequest ?
                aRequest.name : "(null)") + ", flags = " + aStateFlags);

This error is irritating because just accessing aRequest.name throws the error, so I can't even null-check. *sigh*

We do have |domDoc.location| available at this point, which returns a giant URL like: view-source:data:text/html;charset=utf-8,%3Cpre%3E[...etc...] But I think the real problem here is that aRequest.name should exist, but doesn't.

I also noticed that when a XUL window loads (eg, the preferences window) aRequest.name is a file:// URL, whereas domDoc.location is a chrome:// URL?! We can probably tighten up these checks, but I'm not really sure what the best way to go is.

Comment 4

[Justin Dolske [:Dolske]]

From IRC:

<gavin> ! binds tighter than instanceof
<gavin> so that should be (!(domDoc instanceof Ci.nsIDOMHTMLDocument))

That might allow us to bail out early to avoid the check, not being able to check aRequest.name still seems like a bug.

Comment 5

[Justin Dolske [:Dolske]]

Attachment: Patch for review, v.1

Fixes the logic error Gavin noticed. The doc we get from a View Selection Source is a nsIDOMHTMLDocument, so this doesn't actually help with the reported issue.

I think this bug should be moved to Firefox:View Source, and the underlying issue (accessing aRequest.name throwing) fixed there.

Comment 6

[Justin Dolske [:Dolske]]

Comment on attachment 279391 [details] [diff] [review]
Patch for review, v.1

Checked in order-of-operation fix.

Checking in toolkit/components/passwordmgr/src/nsLoginManager.js;
/cvsroot/mozilla/toolkit/components/passwordmgr/src/nsLoginManager.js,v  <--  nsLoginManager.js
new revision: 1.16; previous revision: 1.15

Comment 7

[Justin Dolske [:Dolske]]

Moving to Firefox:View Source.

I don't think this is actually a blocker. Other than generating some console noise, there's no other effect I can see. This is working fine when it's expected to.

Gavin mentioned wanting to have a way to have the WebProgressListener caller not even call us in cases like these (since we're never going to be filling in passwords on View Source or XUL pages), but I think that's fodder for some other bug.

Comment 8

[Jesse Ruderman]

I filed bug 394693 on adding a strict warning to catch bugs like that.

Comment 11

[Tony Chung [:tchung]]

another entry point: same error fired when trying to view-source a chrome:// protocol.   (eg. view-source:chrome://pippki/content/resetpassword.xul)

Comment 13

[Valery Kondakoff]

I'm still getting the Error: [Exception... "Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIRequest.name]"  nsresult: "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)"  location: "JS frame :: file:///C:/Program%20Files/Shredder/components/nsLoginManager.js :: anonymous :: line 315"  data: no]
Source File: file:///C:/Program%20Files/Shredder/components/nsLoginManager.js
Line: 315

with build Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090218 Thunderbird/3.0b2 when trying to view the message source. Should this be fixed in the final TB3.0b2?

Comment 14

[Radek Antoniuk]

Bug still in Mozilla Firefox 3.0.10.


[Exception... "Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIRequest.name]"  nsresult: "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)"  location: "JS frame :: file:///C:/Program%20Files/Mozilla%20Firefox%203%20Beta%205/components/nsLoginManager.js :: anonymous :: line 282"  data: no]
file:///C:/Program%20Files/Mozilla%20Firefox%203%20Beta%205/components/nsLoginManager.js
Line 282

Comment 16

[samspade]

I got it also with thunderbird 3.0 beta 4 under Linux  when asking for the source of a message:
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4
same error but on a different line (of course)
location: "JS frame :: file:///opt/thunderbird/components/nsLoginManager.js :: anonymous :: line 328"  data: no]
Source File: file:///opt/thunderbird/components/nsLoginManager.js
Line: 328

source of the line:
                   (aRequest ?  aRequest.name : "(null)") +

Comment 17

[Davide Ficano]

The error triggers when a pageDescriptor is used to load pages from cache

Something similar/identical to
http://mxr.mozilla.org/mozilla-central/source/toolkit/components/viewsource/content/viewSourceUtils.js#150

this.progress.addProgressListener(this, nsIWebProgress.NOTIFY_STATE_DOCUMENT);
var pageLoader = this.webShell.QueryInterface(
                Components.interfaces.nsIWebPageDescriptor);
pageLoader.loadPage(pageDescriptor, displayType);

The error appears also on with rv:1.9.2b6pre Gecko/20091225 Namoroka/3.6b6pre

Comment 18

[max221]

I'm also getting this; Tbird 3.01 windows xp when viewing source:

Error: [Exception... "Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIRequest.name]"  nsresult: "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)"  location: "JS frame :: file:///C:/Program%20Files/Mozilla%20Thunderbird/components/nsLoginManager.js :: anonymous :: line 328"  data: no]
Source File: file:///C:/Program%20Files/Mozilla%20Thunderbird/components/nsLoginManager.js
Line: 328

Comment 23

[alex_mayorga]

Is bug 464999 a duplicate too?

Comment 24

[Alexander Bergmann]

I can confirm this bug with Thunderbird 7.0.1 and an IMAP account.

1. Create a New Profile
2. Add IMAP account
3. Restart Thunderbird
4. Create a New Message, e.g. with "Save As Draft"
4. Select the Message and click "View -> Message Source"
5. Open the Error Console ("Tools -> Error Console")

Error: [Exception... "Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIRequest.name]"  nsresult: "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)"  location: "JS frame :: jar:file:///usr/lib/thunderbird-7.0.1/omni.jar!/components/nsLoginManager.js :: <TOP_LEVEL> :: line 293"  data: no]
Source File: jar:file:///usr/lib/thunderbird-7.0.1/omni.jar!/components/nsLoginManager.js
Line: 293

Arch Linux / Thunderbird 7.0.1

Comment 25

[Justin Dolske [:Dolske]]

Would someone like to write a trivial patch to just comment out the log() line that generates this? You'll be eligible for a free beer via bug 700000! ;-)

Comment 26

[Christian Sonne [:cers]]

It seems to me that this bug has been fixed by bug 639092?