Closed
Bug 368175
Opened 19 years ago
Closed 17 years ago
[1.8 branch] crash with "direction:rtl" and "-moz-column"
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: hlbyichi, Unassigned)
References
()
Details
(Keywords: rtl)
Attachments
(2 files, 1 obsolete file)
1.35 KB,
patch
|
dbaron
:
review+
dbaron
:
superreview+
|
Details | Diff | Splinter Review |
1.22 KB,
patch
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; zh-tw) AppleWebKit/418.9.1 (KHTML, like Gecko) Safari/419.3
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1) Gecko/20061026 BonEcho/2.0
If there are CSS rules "direction: rtl", nested "-moz-column", and chinese characters ( not tried other unicode characters yet ), it always crashed. Even if there is no nested column, it behaves in a weird way.
example: http://hlb.yichi.org/test/firefox/crash-by-column.html
Reproducible: Always
Steps to Reproduce:
1. open firefox
2. link to http://hlb.yichi.org/test/firefox/crash-by-column3.html
Actual Results:
crash every time
Comment 1•19 years ago
|
||
WFM using Mac trunk.
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → 1.8 Branch
Comment 2•19 years ago
|
||
Possibly related to (or duplicate of) bug 288467 / bug 339081.
Comment 4•19 years ago
|
||
I tested it on Minefield 3a1 and no crash.
Comment 5•19 years ago
|
||
Test on Windows XP with 2.0.0.2pre (2007020204) will not crash. Tab which opens the url will freeze but can be turn off.
Can anyone confirm this is still a branch crasher?
It doesn't crash in my Mac 2.0.0.3 build.
Updated•18 years ago
|
Summary: crash when "direction:rtl", "-moz-column" come together → [1.8 branch] crash with "direction:rtl" and "-moz-column"
Comment 9•18 years ago
|
||
It still crash Firefox 2.0.0.7/OSX 10.4.10.
But Works for me under
Minefield3.0a9/OSX 10.4.10
Comment 10•17 years ago
|
||
Mass-assigning the new rtl keyword to RTL-related (see bug 349193).
Keywords: rtl
Comment 11•17 years ago
|
||
The testcases are misrendered in Fx 2.0.0.20 and eventually crash. They work without anyproblems in Firefox 3 and higher.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Comment 12•17 years ago
|
||
Daniel, mind creating a crashtest for this while you're here (also for the other bugs you've been triaging of late in Layout)? Information on how to write reftests is here:
http://mxr.mozilla.org/mozilla-central/source/layout/tools/reftest/README.txt
Crashtests are just a slight variant of reftests that use the "load" type rather than the "==" or "!=" types. If you have any questions on how to do this, ask here and people will be more than glad to answer questions.
Flags: in-testsuite?
Comment 13•17 years ago
|
||
This crashes Fx 2.0.0.20 every time.
(In reply to comment #12)
> Daniel, mind creating a crashtest for this while you're here (also for the
> other bugs you've been triaging of late in Layout)?
Not at all. I intended to learn more about these anyway after I'm finished with the remaining unconfirmed Layout bugs.
I hope module peers are ok to ask for review?
Attachment #354445 -
Flags: superreview?(bzbarsky)
Attachment #354445 -
Flags: review?(bzbarsky)
Comment 14•17 years ago
|
||
Afaik, you don't need to ask for review, you can just check it in.
At the beginning you probably should be asking for review, especially for reftests.
In this case, are you sure that it would crash inside the harness? In the harness, it's being loaded inside an iframe... so would the window.resize still do what you think? And are you sure it would have an effect before the harness moves on to the next page?
Comment 16•17 years ago
|
||
(In reply to comment #15)
> At the beginning you probably should be asking for review, especially for
> reftests.
I'll keep that in mind.
> In this case, are you sure that it would crash inside the harness? In the
> harness, it's being loaded inside an iframe... so would the window.resize
> still do what you think? And are you sure it would have an effect before
> the harness moves on to the next page?
The resize looses it's effect within an iframe.
Are the width and height of the iframe defined? I noticed if my own iframe can show the complete testcase it only crashes on user action, while it always crashes if the iframe is smaller than the space needed.
800 width x 1000 height.
That said, you could just put an iframe inside the testcase and resize the iframe in the testcase itself.
Comment 18•17 years ago
|
||
(In reply to comment #17)
> That said, you could just put an iframe inside the testcase and resize the
> iframe in the testcase itself.
Ok, that does the trick.
Attachment #354445 -
Attachment is obsolete: true
Attachment #354450 -
Flags: superreview?
Attachment #354450 -
Flags: review?
Attachment #354445 -
Flags: superreview?(bzbarsky)
Attachment #354445 -
Flags: review?(bzbarsky)
Attachment #354450 -
Attachment is patch: true
Attachment #354450 -
Attachment mime type: application/octet-stream → text/plain
Attachment #354450 -
Flags: superreview?
Attachment #354450 -
Flags: superreview+
Attachment #354450 -
Flags: review?
Attachment #354450 -
Flags: review+
Comment on attachment 354450 [details] [diff] [review]
crashtest, v2
r+sr=dbaron (although if you need only the small width and not the resizing, you could probably just use a div)
Comment 20•17 years ago
|
||
(In reply to comment #19)
> (From update of attachment 354450 [details] [diff] [review])
> r+sr=dbaron (although if you need only the small width and not the resizing,
> you could probably just use a div)
Yaeh, no need for complexity. This works just as fine.
Keywords: checkin-needed
![]() |
||
Comment 21•17 years ago
|
||
Pushed http://hg.mozilla.org/mozilla-central/rev/9f80cbefc185 with that last attachment.
Flags: in-testsuite? → in-testsuite+
Keywords: checkin-needed
You need to log in
before you can comment on or make changes to this bug.
Description
•