Closed Bug 15856 Opened 20 years ago Closed 20 years ago

[PP] hitting RETURN in open location dialog fails

Categories

(Core :: XUL, defect, P1, blocker)

PowerPC
Mac System 8.5
defect

Tracking

()

VERIFIED FIXED

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.
and once you hit "stop" to stop the stalled load, you can never go to another
webpage until you quit the app.
Assignee: don → law
Priority: P3 → P1
Target Milestone: M11
Bill, is this our bug?
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.
Whiteboard: [PDT-]
Though a blocker, not holding for dogfood.  Putting on [PDT-] radar.
Folks, this is part of the pre-checkin tests we are telling all developers to
run.  Please re-consider one or the other.
Whiteboard: [PDT-] → [PDT+]
changing to PDT+ per JAR, Jevering, & Phil because it is blocking a precheckin
test.
QA Contact: don → paulmac
Blocks: 16654
This is working on Linux build of 101808. Will check Mac next.
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
Still not working on 101809 Mac build. I think this bug may have set a record
for most []'s.
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.
Summary: [BLOCKER][DOGFOOD][PP] open location dialog doesn't ever go to the page → [PP] hitting RETURN in open location dialog fails
Whiteboard: [PDT+]
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.
Blocks: 16950
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.
Blocks: 17432
Status: NEW → RESOLVED
Closed: 20 years ago
Depends on: 17529
Resolution: --- → FIXED
Whiteboard: problem understood
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.
No longer depends on: 17529
Status: RESOLVED → VERIFIED
okay, verified for the original problem using 10/29 builds
No longer blocks: 17432
You need to log in before you can comment on or make changes to this bug.