If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

No error feedback going to nonexistant url

VERIFIED FIXED in M13

Status

Core Graveyard
Tracking
P1
major
VERIFIED FIXED
19 years ago
a year ago

People

(Reporter: Akkana Peck, Assigned: Warren Harris)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

19 years ago
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.

Updated

19 years ago
Priority: P3 → P1
Target Milestone: M7

Comment 1

19 years ago
Set target milestone to M7 and changed priority to P1.

Updated

19 years ago
QA Contact: 3853 → 4079

Updated

19 years ago
Summary: No error feedback going to nonexistant url → [PP]No error feedback going to nonexistant url
(Reporter)

Updated

19 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

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

Updated

19 years ago
Assignee: don → radha
Target Milestone: M7 → M9

Comment 3

19 years ago
Radha, is this our bug or a netlib problem?

Comment 4

19 years ago
*** Bug 7890 has been marked as a duplicate of this bug. ***
I can't reproduce this anymore. Can someone verify? Thanks.

Comment 6

19 years ago
Akkana, does this happen to you anymore?
(Reporter)

Comment 7

19 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?

Comment 8

19 years ago
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.

Comment 10

19 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.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
This got fixed recently in necko. You'll see a 404 Not Found error

Updated

18 years ago
Status: RESOLVED → REOPENED

Comment 12

18 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.
cc'ing warren. Did anything regress in necko?

Updated

18 years ago
Resolution: FIXED → ---

Comment 14

18 years ago
Clearing FIXED resolution due to reopen.

Updated

18 years ago
Target Milestone: M11 → M13

Comment 15

18 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.
Is this still a problem? Can someone verify?

Comment 17

18 years ago
yup still a problem on 1/5 build.
(Reporter)

Comment 18

18 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.
Assignee: radha → warren
Status: REOPENED → NEW
The 404 error doesn't show up anymore. Passing to necko team for
investigation...
(Assignee)

Updated

18 years ago
Depends on: 13920, 14696, 16026
(Assignee)

Comment 20

18 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

18 years ago
Status: NEW → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 21

18 years ago
I think this works now. I get a dialog.

Updated

18 years ago
Status: RESOLVED → VERIFIED

Comment 22

18 years ago
verified in 1/18 build.

Comment 23

18 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

17 years ago
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.