Closed Bug 4808 Opened 25 years ago Closed 25 years ago

No error feedback going to nonexistant url

Categories

(Core Graveyard :: Tracking, defect, P1)

Product:
Core Graveyard
Component:
Tracking
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: akkzilla, Assigned: warrensomebody)

References

(
URL
)

Details

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.
Priority: P3 → P1
Target Milestone: M7
Set target milestone to M7 and changed priority to P1.
QA Contact: 3853 → 4079
Summary: No error feedback going to nonexistant url → [PP]No error feedback going to nonexistant url
OS: Linux → All
Hardware: PC → All
Summary: [PP]No error feedback going to nonexistant url → No error feedback going to nonexistant url
This got caught in a bulk-change to [PP], but it's a problem on all platforms.
Assignee: don → radha
Target Milestone: M7 → M9
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.
Status: NEW → ASSIGNED
Target Milestone: M9 → M10
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
This got fixed recently in necko. You'll see a 404 Not Found error
Status: RESOLVED → REOPENED
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?
Resolution: FIXED → ---
Clearing FIXED resolution due to reopen.
Target Milestone: M11 → M13
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.
Assignee: radha → warren
Status: REOPENED → NEW
The 404 error doesn't show up anymore. Passing to necko team for
investigation...
Depends on: 13920, 14696, 16026
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.
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
I think this works now. I get a dialog.
Status: RESOLVED → VERIFIED
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
QA Contact: sujay → gerardok
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.