Closed
Bug 4808
Opened 26 years ago
Closed 25 years ago
No error feedback going to nonexistant url
Categories
(Core Graveyard :: Tracking, defect, P1)
Core Graveyard
Tracking
Tracking
(Not tracked)
VERIFIED
FIXED
M13
People
(Reporter: akkzilla, Assigned: warrensomebody)
References
()
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.
Summary: No error feedback going to nonexistant url → [PP]No error feedback going to nonexistant url
Reporter | ||
Updated•26 years ago
|
OS: Linux → All
Hardware: PC → All
Summary: [PP]No error feedback going to nonexistant url → No error feedback going to nonexistant url
Reporter | ||
Comment 2•26 years ago
|
||
This got caught in a bulk-change to [PP], but it's a problem on all platforms.
Comment 5•26 years ago
|
||
I can't reproduce this anymore. Can someone verify? Thanks.
Reporter | ||
Comment 7•26 years ago
|
||
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.
Updated•26 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M9 → M10
Comment 9•26 years ago
|
||
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.
Comment 10•26 years ago
|
||
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.
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 11•25 years ago
|
||
This got fixed recently in necko. You'll see a 404 Not Found error
Comment 12•25 years ago
|
||
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.
Comment 13•25 years ago
|
||
cc'ing warren. Did anything regress in necko?
Comment 14•25 years ago
|
||
Clearing FIXED resolution due to reopen.
Comment 15•25 years ago
|
||
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.
Comment 16•25 years ago
|
||
Is this still a problem? Can someone verify?
Comment 17•25 years ago
|
||
yup still a problem on 1/5 build.
Reporter | ||
Comment 18•25 years ago
|
||
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.
Updated•25 years ago
|
Assignee: radha → warren
Status: REOPENED → NEW
Comment 19•25 years ago
|
||
The 404 error doesn't show up anymore. Passing to necko team for
investigation...
Assignee | ||
Updated•25 years ago
|
Assignee | ||
Comment 20•25 years ago
|
||
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.
Assignee | ||
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 21•25 years ago
|
||
I think this works now. I get a dialog.
Comment 22•25 years ago
|
||
verified in 1/18 build.
Comment 23•25 years ago
|
||
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.
Comment 24•24 years ago
|
||
I am not the qa_contact for this bug...Gerardo, please reassign...thanks
QA Contact: sujay → gerardok
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•