679 bytes, patch
|Details | Diff | Splinter Review|
693 bytes, patch
av (gone): review+
Peter Lubczynski: superreview+
|Details | Diff | Splinter Review|
2.63 KB, text/plain
This one may be a dupe of bug 84681. But that one comments on using the code in nsObjectFrame.cpp nsPluginInstanceOwner to patch nsPluginInstanceOwner in nsPluginViewer.cpp. It was also verified fixed on the branch prior to RTM. This one is crashing in nsObjectFrame.cpp. It does appear to be fixed on the Trunk. Dupe it or mark it fixed if appropriate. I'll include the stack and comments for good measure. nsPluginInstanceOwner::ProcessEvent() [nsObjectFrame.cpp line 2908] nsPluginInstanceOwner::DispatchMouseToPlugin() [nsObjectFrame.cpp line 2875] nsPluginInstanceOwner::MouseDblClick() [nsObjectFrame.cpp line 2851] nsEventListenerManager::HandleEvent() [nsEventListenerManager.cpp line 1265] nsGenericElement::HandleDOMEvent() [nsGenericElement.cpp line 1673] Source File : nsObjectFrame.cpp line : 2908 (34407607) URL: www.ultrashock.com (34407607) Comments: interacting with Flash Movie (34406962) URL: http://www.purepath.co.uk (34406962) Comments: Following site instructions to zoom in on a product block diagram illustration (Option-click) (34398726) Comments: Viewing a Quicktime VR (34360063) URL: http://fr.barbie.com/ (34360063) Comments: Trying to dress the mannequin (34306511) URL: www/Corel.com (34306511) Comments: Chatting on IM (34302470) URL: http://abadan.8k.com (34302470) Comments: scrolling with microsoft intellimouse (34285818) URL: http://www.elvis.com (34285818) Comments: Was viewing an IPIX virtual tour of Graceland at elvis.com while another browser window was open to espn.com's baseball scoreboard. (34270483) Comments: waiting for a quicktime movie to download
Adding crash and topcrash keywords to make talkback happy.
Keywords: crash, topcrash
Petersen, can you see if you can reproduce this? Thanks!
Assignee: av → peterlubczynski
i could repro a crash on going to fr.barbie.com and clicking on the yellow flower vase in the flash movie..dunno if that's the same crash.
uh oh..i meant 1 click on the the printer 2 then immediately click on the 'orange' vase you should crash
Status: NEW → ASSIGNED
Keywords: nsbranch, testcase
Priority: -- → P1
Target Milestone: --- → mozilla0.9.5
I was unable to reproduce this on Mac, but I did notice that at one point we could crash if mWidget is null. There was a check for this before, but it was removed. My patch adds this back in but I'm not sure this will fix this bug if this bug is still happeneing.
Lowering to P2 because it is hard to reproduce.
Priority: P1 → P2
There was a single comment in the M094 data today, it might be a viable place to try to repro this one: (35677588) Comments: Nokia Music Player pop up window... The user didn't list a URL. But this one is likely: http://www.nokia.com/phones/3330/musicplayer.html and click on one of the links in the body. I tried to crash it but was unsuccessful. Maybe someone else can.
peterl - since you have a null pointer check patch for this bug, I'm wondering if we should take your patch for the branch. Perhas you can check into the trunk after r and sr and then we can see if the talkback incidents for this lessens on the trunk.
I still need to test this to make sure it doesn't cause regressions in edge cases.
Whiteboard: [Need ETA] → [ETA:9.29]
Whiteboard: [ETA:9.29] → [ETA:10.1] [seeking reviews]
Fixed up the patch. We should not be in ProcessEvent if we don't have a native window to draw too! I'm not sure this will fix this crash, if it's even happening still, but it shouldn't hurt. It's a protective measure, but I don't see how we can even be inside ProcessEvent if window is null. Andrei, can you review?
Comment on attachment 51583 [details] [diff] [review] updated patch r=av
Attachment #51583 - Flags: review+
Comment on attachment 51583 [details] [diff] [review] updated patch sr=attinasi marc super reviewed this, however, both he and I now don't think this patch will fix this top crash as talkback indicates a problem in nsObjectFrame.cpp and this patch is for nsPluginViewer.cpp
I tried all the testcases in this bug and I can not reproduce, adding minus. I need very detailed steps on how to reproduce because this is likely an isolated event problem.
Keywords: nsbranch → nsbranch-
Whiteboard: [ETA:10.1] [seeking reviews]
" Additional Comments From shrirang khanzode 2001-08-23 10:51 " ..is when I was able to repro this crash. But on later builds, I could not, I will try on latest branch build and see if I can get one.
M094 data shows ten incidents under this signature. No meaningful comments: (35987260) MacOS version 9.1 - trying to load a Shockwave movie (36385726) MacOS version 9.0.4 - flash animation Updating summary. shrirang, any luck with a repro for this one?
Summary: N610 crash with plugins [@ nsPluginInstanceOwner::ProcessEvent] → N610, M094 crash with plugins [@ nsPluginInstanceOwner::ProcessEvent]
Forgot to update this bug...I still cannot reproduce. Will try again :(
Hmm...the second null pointer check patch in this bug is for "pluginInstanceOwner" (notice no ns and lowercase) but this bug is about the other crash, in nsObjectFrame.cpp. However, looking at today's NS62 talback rankings, there is a NEW crash in this method (ranked 21st today!) Since this patch has a review and super review, I checked it into the trunk. I'm leaving this bug open to deal with the crash in nsObjectFrame.cpp. On that trace, latest incident at 2001-10-11 11:56:4 does not indicate any comments to help reproduce but goes through another kind of mouse event: nsPluginInstanceOwner::ProcessEvent() [nsObjectFrame.cpp, line 2994] nsPluginInstanceOwner::DispatchMouseToPlugin() [nsObjectFrame.cpp, line 2964] nsPluginInstanceOwner::MouseOut() [nsObjectFrame.cpp, line 2947] nsEventListenerManager::HandleEvent() [nsEventListenerManager.cpp, line 1306] nsGenericElement::HandleDOMEvent() [nsGenericElement.cpp, line 1686]
Keywords: patch, testcase → qawanted
Summary: N610, M094 crash with plugins [@ nsPluginInstanceOwner::ProcessEvent] → N610, M095 crash with plugins [@ nsPluginInstanceOwner::ProcessEvent]
The above comments show only one incident on M095 and no Trunk crashes in the last ten days of data. However, the comments provide a number of sites for use in testing/repro with the N620 release.
Summary: N610, M095 crash with plugins [@ nsPluginInstanceOwner::ProcessEvent] → N620, M095 crash with plugins [@ nsPluginInstanceOwner::ProcessEvent]
I now see this on my Carbon Trunk build, but ONLY in a debug build by simply clicking to play a Quicktime movie. It works fine in a commercial build though, weird. Good thing is that I break in CW7 and now see what's going on: http://lxr.mozilla.org/mozilla/source/layout/html/base/src/nsObjectFrame.cpp#3195 I think the cast to an EventRecord here may not be correct, however CW7 hangs when I try to expand the nsGUIEvent and doesn't break in that method when I set a breakpoint earlier. Greer: does talkback see this crash anymore in OS9? Maybe it's just OSX now?
OS: Mac System 9.x → All
Peter, somehow I missed your comment on 12-13. Sorry about that. I just checked the Talkback data and don't find any incidents on M097 or the Trunk With the nsPluginInstanceOwner::ProcessEvent signature, nor any crashes in nsObjectFrame.cpp Last release having this signature was N621. Marking WFM.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
Crash Signature: [@ nsPluginInstanceOwner::ProcessEvent]
You need to log in before you can comment on or make changes to this bug.