Closed Bug 15856 Opened 25 years ago Closed 25 years ago

[PP] hitting RETURN in open location dialog fails

Categories

(Core :: XUL, defect, P1)

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: 25 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.