Closed Bug 88936 Opened 19 years ago Closed 19 years ago
After visiting foxnews
.com, can't use URL bar
- using branch bits from 7/2/01, mac - go to www.foxnews.com - 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 toolbar.
this is an rtm stopper. i've been able to duplicate it twice.
this may have something to do with plugins (foxnews.com 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.
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.
really --> event handling
Assignee: asa → joki
Component: Browser-General → Event Handling
QA Contact: doronr → madhur
Is there any tie-in to http://bugzilla.mozilla.org/show_bug.cgi?id=84243 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.
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
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: SCENARIO 1: =========== 1. i went to different websites before I went to www.foxnews.com 2. typed another url and hit enter -----Nothing happened - it stayed at foxnews.com 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. SCENARIO 2: =========== 1. I went to www.macromedia.com (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
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!
Status: NEW → ASSIGNED
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. r=bnesse.
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 proccess.
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 disappear. 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 Shockwave.
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 nsPluginViewer.cpp. 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.
Status: ASSIGNED → RESOLVED
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 www.macromedia.com actual: ======= the entire page containing flash is not displayed at all. 2. i can give u another website. go to http://www.home.com/index_flash.html actual: ======= again, the page contents are not getting displayed. expected: ========= 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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
note that foxnews.com 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.
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 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.
Status: RESOLVED → VERIFIED
*** 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.