Closed Bug 255627 Opened 20 years ago Closed 19 years ago

Search Bar crashing when entry there and new one dragged into bar [@ ntdll.dll - jsd_FunctionCallHook ]

Categories

(Firefox :: Search, defect)

Product:
Firefox
Component:
Search
Version:
1.0 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: jliebson, Assigned: p_ch)

References

Details

(Keywords: crash)

Crash Data

Attachments

(2 files)

A file created by Talkback
59.85 KB, text/plain
Details
HTML testcase
776 bytes, text/html
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040814 Firefox/0.9.1+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040814 Firefox/0.9.1+

If there is already an entry in the Search Bar (at least for the Google engine)
and you drag a new entry into the Bar from a web page, Firefox crashes.

Reproducible: Always
Steps to Reproduce:
1. Look up something using Google in the Search Bar
2. From that search, drag a new term into the Bar.
3.

Actual Results:  
Firefox crashes. This does not happen if you first clear the Search Bar and then
drag the new search term into the Bar.

Expected Results:  
Either nothing or the new search term should be `honored.'
John: Could you provide TalkBack incident ID?
Severity: normal → critical
Keywords: crash
Reply to Comment #1: Talkback does not work for me. I've tried it with both
Firefox and Thunderbird, watched it try eight or ten times to submit a report,
given up.

I might be able to do a screen capture of the file that is created when FF
crashes. If I can do so, what would I do with it? (That is, how and where would
I submit the file?)
Screen capture of file does not sounds useful for me. You should be able to
attach file, just click "Create a New Attachment" link on this page.
In reply to Commment #3:I don't know if this is what you asked me for. If not,
please provide additional details and I'll see what I can do.

(I just installed Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2)
Gecko/20040816 Firefox/0.9.1+, including Talkback, tried draging something into
the search box, FF crashed, and, as always, the Feedback Agent simply will not
deliver the information from my computer.)
The same thing happens to me.  I'm surprised more people haven't noticed this. 
I'm not prompted to send TalkBack info.  However if I look at the MS event log
it says: 

Faulting application firefox.exe, version 1.0.0.0, faulting module js3250.dll,
version 4.0.0.0, fault address 0x0001c6ed.

Maybe that helps, let me know if I can help in any other way.
I'm seeing this in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b)
Gecko/20050209 Firefox/1.0+

My Talkback IDs are TB3593285M and TB3618645E.
Stacks for both incidents have only:
0x80000001
Summary: Search Bar Crashing when Entry There and New One Dragged into Bar → Search Bar Crashing when Entry There and New One Dragged into Bar [@ 0x80000001 ]
TB2872589K, TB2872290Y, TB2872273M, TB2632941X, TB2330040K
TB2872589K, TB2872290Y, TB2872273M, TB2632941X, TB2330040K
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
pd: Your incidents are unfortunatelly too old and was deleted from Talkback
database. The oldest incident in database has number TB3198711. Do you have any
newer?
Adam: Sure, the bug is extremely consistent/annoying. Here's half a dozen
talkback entries I just genereted:

TB3643791G, TB3643771K, TB3643755W, TB3643744E, TB3643731X, TB3643480G

Apologies for the duplicate postings above, caused by over-zealous AutoCopy.
Adam: Sure, the bug is extremely consistent/annoying. Here's half a dozen
talkback entries I just generated:

TB3643791G, TB3643771K, TB3643755W, TB3643744E, TB3643731X, TB3643480G

Apologies for the duplicate postings above, caused by over-zealous AutoCopy.
TB3643791G (others are nearly same):
ntdll.dll + 0x1095 (0x7c901095)
jsd_FunctionCallHook 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/js/jsd/jsd_step.c,
line 223]
js_Interpret 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 1623]
js_Invoke 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 958]
js_InternalInvoke 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 1035]
JS_CallFunctionValue 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/js/src/jsapi.c, line
3698]
nsJSContext::CallEventHandler 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/dom/src/base/nsJSEnvironment.cpp,
line 1297]
GlobalWindowImpl::RunTimeout 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/dom/src/base/nsGlobalWindow.cpp,
line 5350]
GlobalWindowImpl::TimerCallback 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/dom/src/base/nsGlobalWindow.cpp,
line 5712]
nsAppShellService::Run 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/xpfe/appshell/src/nsAppShellService.cpp,
line 495]
main 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/browser/app/nsBrowserApp.cpp,
line 58]
kernel32.dll + 0x16d4f (0x7c816d4f)
Summary: Search Bar Crashing when Entry There and New One Dragged into Bar [@ 0x80000001 ] → Search Bar crashing when entry there and new one dragged into bar [@ ntdll.dll - jsd_FunctionCallHook ]
Version: unspecified → 1.0 Branch
*** Bug 283387 has been marked as a duplicate of this bug. ***
Just installed the latest firefox 1.0.1 on my XP pro 64 bit edition (RC2) and
the bug seems to have neen resolved. Can someone confirm this on a standard XP
32bit install with the latest release just in case this is just XP 64 being more
stable than XP 32.
Just answering my last post, XP 64 doesn't exhibit this bug but XP 32 does, even
with the 1.0.1 security update applied. Tried enabling DEP for all programs in
XP 32 but that didn't make any difference, after a bit more testing I think I
have it narrowed to a problem with Tab Browser preferences. 

Without tabbrowser preferences installed you can type a search into the search
bar then drag and drop some text into the search bar and the program behaves
normally. 
With tabbrowser preferences installed doing the same thing will cause the
program to exit, even if the option to load searches typed into the toolbar in a
new tab is turned off so that it acts the same way firefox does normally.

I think the main problem could be that firefox has two way of dealing with
searches in the toolbar and this may not have been taken into consideration in
tabbrowser preferences.

1. If you type into the box and press return the search result open in the
current tab.

2. If you highlight some text and drag it into the toolbar search box the
results open a new tab in the foreground.
Attached file HTML testcase — 
I have seen this bug (or at least I think it is this bug) while implementing
something with the dragover method. So I think it is not just restricted to the
search box in firefox.

 In the test case attached. if you select some text and drag it over the input
box FF and Moz 1.8b1 will crash. If you empty the text box first the text will
drag without crashing. 

 If you change the event to onmouseover it doesn’t crash.
 If you change the event handler to not change the edit box then it also
doesn’t crash.

 So I think the issue is a combination of onmouseover and changing the value of
the form field.
I can confirm the test case causes a crash, see TB4051372K

(In reply to comment #18)
> Created an attachment (id=175940) [edit]
> HTML testcase
> 
> I have seen this bug (or at least I think it is this bug) while implementing
> something with the dragover method. So I think it is not just restricted to the
> search box in firefox.
> 
>  In the test case attached. if you select some text and drag it over the input
> box FF and Moz 1.8b1 will crash. If you empty the text box first the text will
> drag without crashing. 
> 
>  If you change the event to onmouseover it doesn’t crash.
>  If you change the event handler to not change the edit box then it also
> doesn’t crash.
> 
>  So I think the issue is a combination of onmouseover and changing the value of
> the form field.
> 


I have been experiencing this bug with 10.0.3 and now 10.0.4. One of the
extensions I had installed ia ResizeSearchBox v0.0.5. After uninstalling it,
dragging text into the search bar when there is already a string there now
works. However, the HTML testcase still causes a crash if I drag the 1's into
that box.
I too can consistently reproduce this crash in XP with FF 1.04.  I had both the
Tabbrowser Preferences and Resize Search Bar extensions but seemed that only
Tabbrowser was causing the crashes.  I don't have the problem on my work
computer which is running Win2K Professional.


Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.9) Gecko/20050711
Firefox/1.0.5

UPDATE: This issue still occurs in 1.0.5. 

To reproduce:

1. Run Firefox
2. Type 'Crash' into search bar when set on Google, proceed to search
3. Clear search bar text
4. Double click on 'Crash' in the Google Query Input, to select it
5. Drag and drop into search bar

Completing these steps for me, causes a new tab to begin to load then Firefox
will crash.
Still experiencing this bug. 

TB9683091M

1.0.7

Very annoying.
*** Bug 279286 has been marked as a duplicate of this bug. ***
*** Bug 310041 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050926
Firefox/1.6a1 ID:2005092604

Can anyone still reproduce this in the latest builds, because I can't seem to
get this crash anymore.
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8/
As I was the originator, I'll reply to #26 that I cannot duplicate the problem
using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20050926
Firefox/1.4 - Build ID: 2005092607
Resolving as WFM per reporter's comments and Ria and Peter's comments in bug 310041.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ ntdll.dll - jsd_FunctionCallHook ]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: