149198 - Crash occurs when dragging selection in URL field during loading of site

Status: VERIFIED FIXED

(Camino Graveyard :: General, defect)

Description

[Chris Petersen]

Build: 2002-06-04-05 trunk
Platform: OS X 10.1.4
Expected Results: Selection should grow or shrink (in URL field) as I move the
mouse.
What I got: Application crash soon after loading page

Steps to reproduce:

1) Type in a url and press return
2) As the url is being processed, place focus in URL and mouse down.
3) Drag a selection out and contine to mouse down.
4) When the page loads, the application should crash.

Comment 1

[Chris Petersen]

Attachment: Stack trace

Comment 2

[saari (gone)]

->pinkerton

Comment 3

[Mike Pinkerton (not reading bugmail)]

i don't see this. in fact, the page doesn't load until i release the mouse button.

Comment 4

[Chris Petersen]

I have an additional recipie that that should reproduce:

1) Type in URL like ebay.com. Leave carat active in field.
2) Press return.
3) As the URL is being processed, drag selection in URL field from right to left
so that the cursor is no longer over field (should be near Stop toolbar icon).
Continue to hold mouse button down.
4) When the page is starting to load, the crash occurs.

Comment 5

[Kathleen :Brade]

pink--actually the page will load if you move the mouse out of the edit field
while it's still down (hold it down outside of the editfield for a second or two).

Comment 6

[Kathleen :Brade]

btw, I can reproduce this crash with an old build (splash screen says .2)

Comment 7

[Mike Pinkerton (not reading bugmail)]

i have no idea why this is crashing. i commented out changing of the text when
the page finishes, no luck. i tried commenting out the changing of the icon. no
luck. i tried commenting out the focusing of the url bar. no luck.

i'm stumped.

Comment 8

[David Haas (gone, not reading mail)]

Attachment: total hack

This doesn't fix the underlying problem, since I can't figure out what the
underlying problem is.

This might not be a fix at all - I can only reproduce the bug 1 time out of 5,
so I might have just had a string of luck.

Anyway, comments appreciated.

Comment 9

[Mike Pinkerton (not reading bugmail)]

i played around with this. basically it locks out the text field. the problem
is, if you stop the page from loading, you have to click out and back in again
to be able to type in the url bar.

any ideas on how to fix that?

Comment 10

[David Haas (gone, not reading mail)]

Attachment: big, heavy fix

I'm psyched.  I think I know why this crash happens. My 
explantation (which may be flawed, of course) is below:

A NSWindow has a single field editor, which gets passed around
anytime something needs to display/edit text.  So when you
click on the URL bar and select text while a webpage is loading,
the URL bar gets the field editor, some text is selected, then
the webpage gets takes the field editor (and throws away all
the URL bar text), writes out a word or two, then the URL bar
gets the field editor back and asks for the words it had selected,
which, of course, is no longer being stored (or the storage has been
freed?) and the browser dies.

This patch makes sure the URL bar gets its very own 
field editor separate from the shared window field editor.  I
have lots of trouble replicating this bug, but I am sure I've had
at least 3 runs which would have been a crash without this patch
but was a non-event with it.  

However, I think the reason an NSWindow has a single field editor
is because they're big, heavy objects.	And this patch keeps creating
a new one for the URL bar every time it wants one (which can be 
fairly often).	So this may be a dumb way to fix this. 

I don't think it would take much more noodling to make the "total hack"
patch work so that you didn't have to click out & back in to retype after
a stop (it's just a matter of setting a new firstResponder, I think),
which is probably a lighter method of doing stuff like this.

Comments appreciated.

(man, and I've even got time to get some zzz's before world cup comes on!)

Comment 11

[David Haas (gone, not reading mail)]

Comment on attachment 88587 [details] [diff] [review]
big, heavy fix

Patch for bug 155710 includes an improved version of this fix.

Comment 12

[Mike Pinkerton (not reading bugmail)]

appears fixed to me.

Comment 13

[Winnie Lam]

verified with 07-29 build on OS 10.1.5.

Tried original report and steps in comment #4.  did not crash in either case.