520424 - Crash [@ objc_msgSend | -[ChildView keyDown:] ] when I search on different terms

Status: RESOLVED WORKSFORME

(Camino Graveyard :: General, defect)

Description

[Stuart Lamble]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6; en-us) AppleWebKit/531.9 (KHTML, like Gecko) Version/4.0.3 Safari/531.9
Build Identifier: Version 1.6.10 (1.8.1.23 2009092522)

After performing an initial search on seek.com.au (an Australian job search website), I can enter alternative search terms in the top left text field. After submitting this data, seek then displays a pop-up telling me to wait while the request is processed. When I confirm this pop-up, Camino crashes.

Reproducible: Always

Steps to Reproduce:
1. Navigate to http://www.seek.com.au/
2. Enter keywords in the field that request them.
3. Submit the search (note that the URL given provides the end result of these three steps.)
4. Enter new keywords in the field.
5. Click on "Submit".
6. Click on "Ok".
Actual Results:  
Camino crashes.

Expected Results:  
Camino should just display the page and operate as normal.

Crashlog will be attached very shortly.

Comment 1

[Stuart Lamble]

Attachment: Output from crash reporter.

Comment 2

[Stuart Morgan]

I can reproduce this is 1.6.10 as long as I replace step 5 with "hit return"; clicking Seek doesn't seem to bring up the dialog.

The good news is that it's fixed in 2.0b4, but since this is so easily reproducible I'll see if there's anything simple we could do in ChildView to prevent this on the 1.6 branch.

Comment 3

[Stuart Lamble]

*headdesk*

Sorry. You're right, "hit return" is what I was actually doing; somehow I got that and "click on submit" mixed up in my mind. As penance, I shall go forth and install Windows ME ... ;)

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

FWIW, on 10.3.9 I get a -[NSView interpretKeyEvents:] frame between objc_msgSend and -[ChildView keyDown:].

Comment 5

[Stuart Morgan]

This is pretty ugly. The key-down handling spawns the alert, which runs a modal loop; during that modal loop the ChildView we are currently running keyDown: in is autoreleased and dealloc'd, then we come back from the dialog and try to keep running the method in the now-destroyed object.

There's nothing super-easy I can see to do here, and I'd be worried about causing some subtle regression in other more common key handling cases if I try to do something tricky. Given that, I think we should just call this WFM (since it doesn't happen in 2.0).

Comment 6

[green1987]

a similar problem was experienced at http://jobapplicationaustralia.com , http://jobapplicationcanada.com
 and fixed in 2.0b4, but since this is so easily reproducible I'll see if there's anything simple we could do in ChildView to prevent this on the 1.6 branch.