Run apprunner. Type http://www.muzilla.org (note the misspelling) in the urlbar and hit return. I get lots of messages on stdout: ---------------------------- -- Find Bookmark Shortcut -- user input: http://www.muzilla.org ---------------------------- FindBookmarkShortcut: in='http://www.muzilla.org' out='' Added page http://www.muzilla.org to the rdf:history datasource Document http://www.muzilla.org loaded successfully but it doesn't in fact load successfully (of course, since it doesn't exist) and doesn't give me any error indication, just continues to display the page it was previously displaying.

Set target milestone to M7 and changed priority to P1.

This got caught in a bulk-change to [PP], but it's a problem on all platforms.

Radha, is this our bug or a netlib problem?

*** Bug 7890 has been marked as a duplicate of this bug. ***

I can't reproduce this anymore. Can someone verify? Thanks.

Akkana, does this happen to you anymore?

Now I see: FindShortcut: in='http://www.muzilla.org' out='null' Loading url http://www.muzilla.org in WEbshell 819cb90 nsDocumentBindInfo::OnStopBinding: Load of URL 'http://www.muzilla.org' failed. Error code: 1 Error loading URL http://www.muzilla.org Document: Done (0.265 secs) Got a handle to forward menu item Setting forward menu item disabled Obtained MenuItem Back Setting Back menuitem to enabled Alert: Alert! did not find a converter or decodernsDocumentBindInfo::OnStopBinding: Load of URL 'file:////builds/tue/mozilla/dist/bin/res/throbber/anim.gif' failed. Error code: 1 If you search back in all that, there is a "can't load url" error message, sort of, but it's buried in the other stuff and hard to find. Then there's a beep from the Alert message. So this is better, but there really ought to be some sort of indication in the UI (like on the status bar, for example) since I assume (hope) these stdout messages won't show up in optimized builds. Sujay, what do you see? I'm curious that Radha and Sujay say they can't reproduce the lack of error message -- what sort of error messages are you seeing, especially in optimized builds?

okay I see exactly the same thing that Akkana sees. I originally thought we were talkign about error messages in the browser itself and not the console.

Akkana's original bug report has the message, Document http://www.muzilla.org loaded successfully Which doesn't happen anymore. As far as providing visual feedback in the browser, the behavior depends on our netcenter integration plan. Like 4.5 we may get redirected to netcenter. Since we are not there yet, I'm hanging in there. Shall look in to any shotterm remedies.

Moving all Apprunner bugs past and present to Other component temporarily whilst don and I set correct component. Apprunner component will be deleted/retired shortly.

This got fixed recently in necko. You'll see a 404 Not Found error

not working in 12/7 build...I tried non-existent URLs and the throbber keeps going....eventually stops and I see "Document Done" in the status area below.. we should see the 404 not found message....I never see it.. tried on Mac, Linux and Win on 12/8 builds of Mozilla.

cc'ing warren. Did anything regress in necko?

Clearing FIXED resolution due to reopen.

Note also that the bogus URL gets added to the URL "stack", so hitting the back button after entering an invalid URL takes you to the most recent valid page -- which is the one still being rendered. And then hitting the forward button will try to take you to the invalid URL.

Is this still a problem? Can someone verify?

yup still a problem on 1/5 build.

If I type "http://foobarbaz" into the urlbar, no page loads, no error dialog pops up, and on stdout I see: FindShortcut: in='http://foobarbaz' out='null' change lock icon to unlock - new document failed to set the page title. Error loading URL http://foobarbaz/ Document: Done (0.768 secs) change lock icon to unlock - new document ! nsSecureBrowserUIImpl found: http://bugzilla.mozilla.org/process_bug.cgi change lock icon to unlock ?(http 804b001e) failed to set the page title. Error loading URL http://www.foobarbaz.com/ Document: Done (0.262 secs) ! nsSecureBrowserUIImpl found: http://bugzilla.mozilla.org/process_bug.cgi change lock icon to unlock ?(http 804b001e) ->>>>>>>>>>>>>> Write Clipboard to memory ->>>>>>>>>>>>>> Read Clipboard from memory FindShortcut: in='http://bugzilla.mozilla.org/show_bug.cgi?id=4808' out='null' change lock icon to unlock - new document WEBSHELL+ = 5 failed to set the page title. Document http://bugzilla.mozilla.org/show_bug.cgi?id=4808 loaded successfully Document: Done (2.209 secs) ! nsSecureBrowserUIImpl found: http://bugzilla.mozilla.org/show_bug.cgi?id=4808 change lock icon to unlock ?(http 0) So yes, there's an error message buried in there somewhere, but it's really hard to find, and the normal user won't be watching stdout for printf messages.

The 404 error doesn't show up anymore. Passing to necko team for investigation...

I don't think this is worth fixing until the new webshell/url-dispatcher is in place. Remember that the way this needs to work is this: We try to load a url, but if we detect it fails (asynchronously), then we try something else (e.g. fixing up www.*.com, etc.) If we run out of things to try, _then_ we should throw up the dialog saying that we failed to load it. See bugs 14696, 16026, 13920 (and possibly others) for more detail.

I think this works now. I get a dialog.

verified in 1/18 build.

Has this problem appeared again as bug 40539 ? It seems to only happen with file:// , but the behavior is exactly the same as this bug.

I am not the qa_contact for this bug...Gerardo, please reassign...thanks