Closed Bug 88936 Opened 19 years ago Closed 19 years ago

After visiting, can't use URL bar


(Core :: DOM: UI Events & Focus Handling, defect, P1, blocker)

Mac System 9.x





(Reporter: mikepinkerton, Assigned: peterlubczynski-bugs)




(Keywords: crash, top100, Whiteboard: [PDT+])


(2 files)

- using branch bits from 7/2/01, mac
- go to
- click back in url bar, type some other webpage hit return 

nothing happens. even in new windows. the only way to browse is with personal
this is an rtm stopper. i've been able to duplicate it twice.
this may have something to do with plugins ( has flash).

i also notice that when the page finishes loading, the proxy icon is disabled.

anyone have any ideas? this is pretty bad. I can repro 100% of the time with the
7/2 branch build.
Keywords: nsBranch, top100
OS: Mac System 8.5 → Mac System 9.x
It's a flash thing. You can't hit enter/return while on a page with flash. They
go to the flash object instead of the browser window.
dear lord, so um, whose bug is this?
I'd guess event handling because the event is going to the wrong `window'.
tagging as RTM stopper.
Whiteboard: [PDT+]
really --> event handling
Assignee: asa → joki
Component: Browser-General → Event Handling
QA Contact: doronr → madhur
Is there any tie-in to with
flash and sidebar?
joki, this is PDT+ bug. Tomorrow, on Tuesday, we'll try to build the
first RTM candidate. It would be good, if this could be resolved ASAP.

So is this Mac only as far as we can find?  Or are we seeing it elsewhere as 
well.  If it is Mac only I'll want some Mac expertise looking at this as well.  
I don't see it in my current branch build on Windows but that's from late last 
week.  I'll update it and see what I find.
Well on my branch build updated this afternoon on Windows I'm not seeing a 
problem so seems like Mac only.  Possibly Mac widget level event dispatch 
problem?  Could still be xp code but thats somewhat less likely.  This'll need 
some Mac specific attention.
Target Milestone: --- → mozilla0.9.3
madhur - can you verify if you can reproduce this consistently on the Mac and
help Joki to reproduce as necessary (if you also had seen this on Win32).

Mac folks on the cc: list - can anyone help joki out on this bug?  Joki - do you
have a Mac accessible to you?

Thanks.  Updating status whiteboard w/current status.
Whiteboard: [PDT+] → [PDT+] No ETA
cc'ing chinsky in case he might have time to look at this. peter, this is a
pretty bad plugin bug. any ideas?
will try to verify
Whiteboard: [PDT+] No ETA → [PDT+] trying to reproduce on Mac
If it's plugins, sounds like mine. I think this is a dup. Is the problem for
sure when we have a plugin on the page? I recall last time I looked I could
reproduce without a plugin and had problems reproducing with plugins. But I
think that was on Win32, so is this Mac only?

Anyway, this testcase looks very reproducable.
What about a simple testcase or with other plugins? Is this flash only?

The problem could be in nsPluginInstanceOwner::GUItoMacEvent, where focus is set
and removed. Perhaps someone with more experience with focus events could let me
know if this is done correctly.
Assignee: joki → peterlubczynski
I was able to reproduce this bug consistently on Mac8.6 -- build ID: 2001070303 
and 2001070503

Steps I conducted:
1. i went to different websites before I went to
2. typed another url and hit enter
-----Nothing happened - it stayed at
3. now when i hit the browser BACK key, the browser crashes giving me the 
following error message -
" The application Netscape6 has unexpectedly quit due to error type 11"
After this the computer hung up. I had to restart the computer also.

1. I went to (since that page also needs flash plugins)
2. the browser crashed immediately and the computer hung up.

If anyone wants, I could show them exactly how I reproduced this bug.
I was not able to reproduce on window2000. It seems to be a MAC specific bug.

Adding keyword - crash
Keywords: crash
correction ---

when the browser crashes it gives the "error of type 3" and not the "error 
of type 11"
That last, one-line patch, lowers the priority of the plugin timer and low and
behold this seems to make the address bar work! Please try it out and let me
know if I'm not crazy!
Keywords: patch
Priority: -- → P1
Whiteboard: [PDT+] trying to reproduce on Mac → [PDT+][fix-in-hand]
Yep, that does appear to fix the problem.
Whiteboard: [PDT+][fix-in-hand] → [PDT+][seeking reviews]
I've tested this against a number of different plugin's with no apparent ill
side effects.

So why does lowering the timer priority fix the problem?
For some reason, the timer is "stealing" away return events before they can be
processed. Without the patch, press return serveral times, quickly, and notice
it does work. To rule out anything else, I removed ALL of the DOMEvent
listeners, and commented out any pience of "focus" code. Even when I commented
out all the code in ::Notify(), it didn't help. Reducing the timer's priority
seemed to be the only thing that would give enough time for the return event to
Rather than lowering the priority, what if we make the timer fire less often? I 
guess I'm still worried that this fix might still cause the the odd key event to 

I'm also curious about why we don't feed null events through from our event loop. 
Why the weird timer to generate them?
The timer has always been there, my guess is because at one point, null events
weren't getting through. Not quite sure, need to investigate but I think that
may be too much of a change to make for the branch.

However, lowering the timer to a fire a little less often at 1000/50 seems to
have done the trick on my debug build! I'll modify the patch with this change if
that's all what's needed to get an sr= and fix this bug.

Whiteboard: [PDT+][seeking reviews] → [PDT+][need sr=]
As I recall being told, we simply don't send null events through our event
queue. I don't know why. The only thing we need to be careful of is not reducing
the frequency to the point where updating lags on shockwave, etc.
I worry that picking the "right" frequency for the timer might also depend on 
machine-specific details such as:
* Key repeat rate
* Machine speed (CPU speed)
* Other things running on the machine.

Basically I'm saying that we need to understand the problem better before 
accepting a fix that seems to work on one machine.
Why is the plugin timer even effecting the address bar? When I put coments
around the code in Notify(), still had the same problem.

How do we go about choosing a number? Try on the slowest machine? I wonder how
this number was choosen orriginally? How do we know we aren't starving Flash or
Okay, here's the deal. Tested on a slow Mac G3 300 and a new Mac G4 400, with
key repeat rate to it's lowest setting.

Currently, the timer is set at 1000/60 which equals 16.6666 ms.
Changing the timer slightly so it's set to 1020/60 which equals 17 ms on the
dot, seems to make this work fine for both the G4 and G3.

It almost looks like 17 is a magic number. I also forgot about full-page
plugins. The timer in nsPluginViewer.cpp will need to be changed the same way.
A minor timer tweak seems safe, sr=sfraser on changing this and 

But I'd love to know why this steals events from the url bar.
Changes made in both trunk and branch, marking FIXED. Timer will now fire at
(1020 /60) ms and not a second too soon.
Closed: 19 years ago
Resolution: --- → FIXED
Whiteboard: [PDT+][need sr=] → [PDT+]
build id : 20010716 - branch
OS : mac8.6

Now, the flash pages are not being displayed at all.

1. go to
the entire page containing flash is not displayed at all.

2. i can give u another website. go to
again, the page contents are not getting displayed.

the page contents containing flash should be dispalyed.

note:- I see this problem only in macintosh. I checked on win2000 - it is
working fine there.

Re-opening the bug.

Resolution: FIXED → ---
note that no longer uses flash on their front page. however, i'm sure 
this bug would still exist on other pages that use flash.
Shouldn't this be a *new* bug... unless the belief is that this checkin caused
this regression? I don't see the connection...
PLEASE don't morph this bug, it's about a completely different issue. If you
can't use the URL bar on a Flash page, then please reopen this one, otherwise
marking FIXED again.

Use bug 90959 for tracking Flash not working on Mac. This seems to be a
regression as it worked in my debug build from last week. Updaing my build now
and please use bug 90959 for Flash not working on Mac.
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
marking this bug verifed as per developers comments. Please refer to bug 90959 
for fuirther updates on Flash not working on Mac.

*** Bug 87197 has been marked as a duplicate of this bug. ***
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.