Closed Bug 14277 Opened 25 years ago Closed 25 years ago

Links are causing Mozilla to crash

Categories

(Core :: Layout, defect, P1)

x86
All
defect

Tracking

()

VERIFIED DUPLICATE of bug 14049

People

(Reporter: shashi, Assigned: vidur)

References

()

Details

(Whiteboard: [TESTCASE] shashi@narain.com)

Under Win32, when the icons are clicked, Mozilla crashes. Under Linux, nothing
happens
Whiteboard: [TESTCASE] shashi@narain.com
Target Milestone: M11
The following comments are based on the 09-17-08-M11 build for Linux and Win32.

In the original URL I provided, the icons' links were constructed as follows:

<a href="JavaScript: someFunction();" onClick="someFunction();">

Since the same function is called via the href and the onClick handler it is
difficult to say which is causing the problem. I have created two testcases to
pinpoint where the problem is coming from.

Testcase 1 (http://www.narain.com/gecko/test8.html):

In this testcase the links are constructed like this...<a href="JavaScript:
someFunction();"> When the icons are clicked under Win32, Mozilla crashes.
Specifically, JS3250.dll goes down. Under Linux, nothing happens when the icons
are clicked.

Testcase 2 (http://www.narain.com/gecko/test9.html):

In this testcase the links are constructed like this...<a
onClick="someFunction();"> When the icons are clicked under Win32, the links
work correctly (although a strange blue border encompasses the icon when it is
clicked). Under Linux, nothing happens but a quick look at my CPU meter shows a
100% load on my P3-450 system which signifies something is happening. 5-10
seconds after clicking an icon, the relevent text appears but without using the
pseudo-transition DHTML that I have coded.

The bottom line is that JavaScript URLS contained within an HREF are causing
Mozilla major problems while onClick handlers give mixed results depending on
the platform.
Blocks: 12761
Priority: P3 → P1
This is, yet again, two bugs.  Please pick one to file as a new bug, so that we
can get the right people looking at each.

Thanks.
With regards to Testcase 1, I remember seeing a thread on the Layout newsgroup
where Brendan mentioned that JavaScript URL's were supposed to be working for
the M9 builds and somehow got busted along the way. This testcase is to show
that it is still not working correctly to the point where on Win32 Mozilla
crashes.

Testcase 2 is very much related to bug 12761 which is a dependant of this bug.
Within Linux we are seeing the same "choking" of the JS Engine as in the DHTML
slide-in from bug 12761. Since the choke from the earlier bug is not witnessed
in Win32 platforms, I was fully expecting that this testcase would be working
fine under Windows, which is the case.

IMHO, I believe that testcase 2 should be part of bug 12761 since they are one
in the same.
Assignee: troy → vidur
I'm crashing in JS code:

NTDLL! 77f76148()
js_GetSlotWhileLocked(JSContext * 0x01afdcc0, JSObject * 0x00cdc4b0, unsigned
long 2) line 242 + 39 bytes
JS_GetPrivate(JSContext * 0x01afdcc0, JSObject * 0x00cdc4b0) line 1308 + 98
bytes
nsJSContext::GetGlobalObject(nsJSContext * const 0x01afde30) line 252 + 17 bytes
nsJSContext::EvaluateString(nsJSContext * const 0x01afde30, const nsString &
{...}, void * 0x00cdc4b0, nsIPrincipal * 0x00000000, const char * 0x00000000,
unsigned int 0, nsString & {...}, int * 0x0125fd24) line 159 + 12 bytes
nsJSInputStream::Eval() line 165 + 55 bytes
nsJSInputStream::Available(nsJSInputStream * const 0x02303ec0, unsigned int *
0x0125ff18) line 105 + 8 bytes
nsFileTransport::Process() line 503 + 42 bytes
nsFileTransport::Run(nsFileTransport * const 0x02305154) line 418
nsThreadPoolRunnable::Run(nsThreadPoolRunnable * const 0x00be7960) line 563 + 12
bytes
nsThread::Main(void * 0x00be7920) line 102 + 18 bytes
_PR_NativeRunThread(void * 0x00be77b0) line 379 + 13 bytes
_threadstartex(void * 0x00be7600) line 212 + 13 bytes
KERNEL32! 77f04f2c()
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
javascript: URLs are resolved on the wrong thread. DUP of 14049.

*** This bug has been marked as a duplicate of 14049 ***
Status: RESOLVED → VERIFIED
Marking as verified duplicate of 14049
Since this bug is fixed, I am removing the testcase from my server.
You need to log in before you can comment on or make changes to this bug.