In this bug report, select something in the Summary or Keywords fields and right click, you'll get the following assertion failure and crash: ASSERTION FAILED: [[newMenuItems objectAtIndex:1] isSeparatorItem] (/Users/matt/Code/WebKit/WebKit/WebCoreSupport/WebContextMenuClient.mm:76 getCustomMenuFromDefaultItems)
Created attachment 12254 [details] Crashlog
I tried and can't reproduce this. Maybe it's fixed already?
I can't reproduce this either. It's possible that it has been fixed, but I am not sure which specific check-in would have addressed this.
Sorry, I could have been clearer in my initial report. I can reliably reproduce this by double clicking on "REGRESSION" in the summary field and then right clicking with r18783. If that doesn't work, Command + A to select everything in the summary field also works - seems to be an issue with word boundaries as selecting only part of a word doesn't trigger the failure.
Looks like this might be fixed, then, because I still cannot reproduce with the more specific instructions (I am at r18804). Matt, could you update and try again? Then if you cannot reproduce, we can close the bug.
Wait never mind, I just realized that your revision number is actually very recent. I wonder why no one else can reproduce this?
(In reply to comment #6) > Wait never mind, I just realized that your revision number is actually very > recent. I wonder why no one else can reproduce this? Assertion failures require a debug build to trip?
(In reply to comment #6) > Wait never mind, I just realized that your revision number is actually very > recent. I wonder why no one else can reproduce this? Confirmed with locally-built DEBUG build of WebKit r18804 with Safari 2.0.4 (419.3) on Mac OS X 10.4.8 (8N1037).
I am using a Debug build also. Dave, does your last comment mean that you *can* reproduce, or that you *cannot*?
I'm also getting this assertion failure (not 100% reliably).
(In reply to comment #9) > I am using a Debug build also. Dave, does your last comment mean that you *can* > reproduce, or that you *cannot*? Sorry, I *am* able to reproduce this assertion failure. I'm using a MBP Core 2 Duo with a Wireless Mighty Mouse (if that makes a difference).
(In reply to comment #11) > I'm using a MBP Core 2 Duo with a Wireless Mighty Mouse (if that makes a difference). A G4 here. Some debug data: (gdb) po defaultMenuItems <NSCFArray 0x22fe6e0>( <MenuItem: 0x6a23b90 Search in Spotlight>, <MenuItem: 0x6a23c00 Search in Google>, <MenuItem: 0x6a30f10 >, <MenuItem: 0x6a23c90 Look Up in Dictionary>, <MenuItem: 0x6a30f80 >, <MenuItem: 0x6a242a0 Cut>, <MenuItem: 0x6a23d20 Copy>, <MenuItem: 0x6a24310 Paste>, <MenuItem: 0x6a30ff0 >, <MenuItem: 0x6a31410 Spelling, submenu: 0x6a30380 ()>, <MenuItem: 0x6a31870 Font, submenu: 0x6a24380 ()>, <MenuItem: 0x6a328b0 Speech, submenu: 0x6a31f30 ()>, <MenuItem: 0x6a330b0 Writing Direction, submenu: 0x6a32950 ()> ) (gdb) po newMenuItems <MenuItem: 0x22121f0 > <MenuItem: 0x6a25490 Spelling, submenu: 0x6a1e580 ()> <MenuItem: 0x6a1e090 > <MenuItem: 0x6a1dcf0 Copy>
I found a way to reproduce this pretty reliably and helped Beth with the steps :)
Looks like this only happens with older version of the app. Boo.
I believe the problem is that we've made new tags that have the same values as old SPI tags used to have. See the change here: http://trac.webkit.org/projects/webkit/changeset/10008 I've got a fix on the way.
Created attachment 12448 [details] Proposed fix
Comment on attachment 12448 [details] Proposed fix Looks good. Why is there a default case in the switch statement in ContextMenu.cpp. In gcc, all the default case does is turn off the often-useful warning for enum values that have no case. If the switch value's type is not an enum, then a "default: break" case does nothing. I think getCustomMenuFromDefaultItems would read better with an early exit rather than most of the function inside an if. I also think it might be best to have this code only trigger on applications compiled against the old WebKit. Tim Hatcher has the details about how we can check this. r=me
Landed as r18864
*** Bug 12433 has been marked as a duplicate of this bug. ***