Closed
Bug 386476
Opened 17 years ago
Closed 17 years ago
Crash [@ nsTextFrameUtils::TransformText] after switching text direction in textarea containing BiDi text
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: ogirtd, Assigned: roc)
References
Details
(Keywords: regression, testcase)
Attachments
(1 file)
503 bytes,
text/html
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070630 Minefield/3.0a6pre
Build Identifier:
Firefox crashes when trying to switch text direction of TEXTAREA containing certain BiDi content.
Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Comment 2•17 years ago
|
||
The testcase is wfm, with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070630 Minefield/3.0a6pre
Reporter, the testcase does crash for you, right?
Do you have a breakpad ID?
http://kb.mozillazine.org/Breakpad
In any case, I think this is likely to be a regression from bug 367177.
> Reporter, the testcase does crash for you, right?
It crash immediately after trying to switch text direction (context menu or CTRL+SHIFT+X) of the textarea.
> Do you have a breakpad ID?
I had to run the testcase many times until the reporter worked (bug 386343).
Here's the crash report:
https://crash-reports.mozilla.com/reports/report/index/83165db3-285a-11dc-9de3-001a4bd46e84?date=2007-07-02-05
Comment 4•17 years ago
|
||
Thanks:
0 nsTextFrameUtils::TransformText(unsigned short const *,unsigned int,unsigned short *,int,unsigned char *,gfxSkipCharsBuilder *,unsigned int *)
1 BuildTextRunsScanner::BuildTextRunForFrames(void *)
2 BuildTextRunsScanner::FlushFrames(int)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Crash after switching text direction in textarea containing BiDi text → Crash [@ nsTextFrameUtils::TransformText] after switching text direction in textarea containing BiDi text
Comment 5•17 years ago
|
||
I can see the crash now too with the keyboard, using CTRL+SHIFT+X.
Comment 6•17 years ago
|
||
I hit this crash a lot during automated testing. It confuses Mac OS X Crash Reporter so much that it often puts the crash into something like "e.crash.log" or "dniw).crash.log" instead of "firefox-bin.crash.log"! My stack is cut off, like Martijn's. Sometimes it comes with
ASSERTION: Attempting to allocate excessively large array: 'Error', file nsTArray.cpp
Flags: blocking1.9?
Assignee | ||
Comment 7•17 years ago
|
||
I get an assertion about frame offsets overlapping, so this is probably related to bug 385270.
Depends on: 385270
Bumping over to roc; close this off if it's fixed by 385270?
Assignee: nobody → roc
Flags: blocking1.9? → blocking1.9+
Comment 9•17 years ago
|
||
This is working now in:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007081605 Minefield/3.0a8pre
But it was also working in yesterday's build.
So I guess this should be marked worksforme?
Assignee | ||
Comment 10•17 years ago
|
||
OK
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Updated•17 years ago
|
Flags: in-testsuite?
Comment 11•12 years ago
|
||
Flags: in-testsuite? → in-testsuite+
Comment 12•12 years ago
|
||
You need to log in
before you can comment on or make changes to this bug.
Description
•