Closed
Bug 15856
Opened 25 years ago
Closed 25 years ago
[PP] hitting RETURN in open location dialog fails
Categories
(Core :: XUL, defect, P1)
Tracking
()
VERIFIED
FIXED
M11
People
(Reporter: mikepinkerton, Assigned: danm.moz)
References
Details
(Whiteboard: problem understood)
launch apprunner
surf normally, it works just fine.
open the "open location" dialog and type in a url, any url.
click ok.
it pretends to load the page you typed (url bar updated to reflect and throbber
starts spinning) but nothing ever happens. spins forever.
this is particularly bad because the open location dialog is right now the only
way you can surf the web on mac because of a bug in the gfx text widget that
hasn't been fixed on the tip.
Reporter | ||
Comment 1•25 years ago
|
||
and once you hit "stop" to stop the stalled load, you can never go to another
webpage until you quit the app.
Apparently so, since they assigned it to you (and now to me :-). I don't think
it's anything we did
(Excuse me; I was eating some dogfood for lunch today and it wouldn't let me
finish that last comment. I'm now using Communicator so I think I'll be able to
finish now...)
...and since I'm away from my Mac, I won't be able to investigate it. I think
it should go to somebody else if you want a real quick fix. Maybe davidm could
have a look?
Assignee: law → danm
Component: XPApps → XP Toolkit/Widgets
Summary: [DOGFOOD] open location dialog doesn't ever go to the page → [BLOCKER][DOGFOOD] open location dialog doesn't ever go to the page
Problem is Mac *and* Unix. Seems to be due to the subject dialog being modal.
After issuing the request to load the new URL, the dialog closes. This seems to
result in some posted events in the nested event queue getting lost. I'm
turning it over to danm, Mr. Modal Dialog himself. cc:ing dp, as requested.
Comment 7•25 years ago
|
||
Folks, this is part of the pre-checkin tests we are telling all developers to
run. Please re-consider one or the other.
Updated•25 years ago
|
Whiteboard: [PDT-] → [PDT+]
Comment 8•25 years ago
|
||
changing to PDT+ per JAR, Jevering, & Phil because it is blocking a precheckin
test.
Updated•25 years ago
|
QA Contact: don → paulmac
Comment 9•25 years ago
|
||
This is working on Linux build of 101808. Will check Mac next.
Updated•25 years ago
|
Summary: [BLOCKER][DOGFOOD] open location dialog doesn't ever go to the page → [BLOCKER][DOGFOOD][PP] open location dialog doesn't ever go to the page
Comment 10•25 years ago
|
||
Still not working on 101809 Mac build. I think this bug may have set a record
for most []'s.
Assignee | ||
Comment 11•25 years ago
|
||
Odd. I never marked this one fixed, though it kind of is. Yes, Linux is working.
The Mac is also working (or for me, anyway) if you hit the OK button in the Open Location
Dialog. Just hitting "return" does nothing. It doesn't even set the status bar spinning; it just
does nothing at all. Those are symptoms different from the "lost events" problem I nearly fixed
this morning. I suspect it's a different problem altogether. Sigh. I'll probably have to triage
that, next.
Updated•25 years ago
|
Summary: [BLOCKER][DOGFOOD][PP] open location dialog doesn't ever go to the page → [PP] hitting RETURN in open location dialog fails
Whiteboard: [PDT+]
Comment 12•25 years ago
|
||
Ah, yes, the return thing is the only current problem. Hitting OK works. Sorry.
Do you want a new bug for the return problem or leave it as is? I'm removing the
[PDT ] and [BLOCKER} and [DOGFOOD] labels for now.
Comment 13•25 years ago
|
||
This is still working on Linux and Windows on 1027 builds. The behavior on the
Mac is that pressing return dismissing the open web location dialog but nothing
is passed into the location bar and nothing is loaded.
Still not a blocker or dogfood or any of that stuff.
Status: NEW → RESOLVED
Closed: 25 years ago
Depends on: 17529
Resolution: --- → FIXED
Whiteboard: problem understood
Assignee | ||
Comment 14•25 years ago
|
||
I'm closing this one and opening a new one to describe the same symptom for reasons described in
that new bug (17529). The primary cause of the symptom from this bug was netlib events being dropped
on the floor after the modal dialog was closed. That's been fixed. So I'm marking this one fixed, but
dependent on the new one, which describes an identical-sounding problem, but from very different causes.
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 15•25 years ago
|
||
okay, verified for the original problem using 10/29 builds
You need to log in
before you can comment on or make changes to this bug.
Description
•