Closed
Bug 386476
Opened 14 years ago
Closed 14 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•14 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•14 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•14 years ago
|
||
I can see the crash now too with the keyboard, using CTRL+SHIFT+X.
Comment 6•14 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•14 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•14 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•14 years ago
|
||
OK
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Updated•14 years ago
|
Flags: in-testsuite?
Comment 11•8 years ago
|
||
crashtest: https://hg.mozilla.org/integration/mozilla-inbound/rev/72d8423cb0e3
Flags: in-testsuite? → in-testsuite+
You need to log in
before you can comment on or make changes to this bug.
Description
•