Closed
Bug 381014
Opened 18 years ago
Closed 17 years ago
BIDI Issue image comes before the inputtext in RTL mode
Categories
(Core :: Layout: Text and Fonts, defect)
Core
Layout: Text and Fonts
Tracking
()
RESOLVED
FIXED
People
(Reporter: shafi_363, Unassigned)
References
Details
(Keywords: rtl, testcase)
Attachments
(1 file, 1 obsolete file)
|
590 bytes,
text/html
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
I have following HTML. The style class 'linkClass' has background image property.
<input type="text">
<a href="#" class="linkClass"></a>
In LTR mode, input text and then image comes. In RTL mode also 'images comes first and then input text'.
It should have been 'input text and then image'
Reproducible: Always
Steps to Reproduce:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML lang="ar" dir="rtl">
<HEAD>
<TITLE> New Document </TITLE>
<style type="text/css">
.linkClass
{
background-image : url('http://www.ablereach.com/csstest/bswirl.gif');
background-position:left bottom;
background-repeat:no-repeat;
font-size:14px;
margin-left:1px;
margin-right:1px;
padding-right:16px;
}
</style>
</HEAD>
<BODY>
<table>
<tr>
<td>
<input type="text">
<a href="#" class="linkClass"></a>
</td>
</tr>
</table>
</BODY>
</HTML>
Actual Results:
For this HTML page locale is set to arabic. In RTL mode from the right-hand side, image comes first and then input text.
Expected Results:
It should be the other way round. inputText should come first and then image.
In LTR mode this works fine. Only in RTL mode Firefox does not render the contents properly
RTL mode does not display input text first and then image. It actually displays image first and then input text.
|
||
Updated•18 years ago
|
Severity: major → normal
Component: General → Layout: BiDi Hebrew & Arabic
Keywords: testcase
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → layout.bidi
Hardware: PC → All
Version: unspecified → 1.8 Branch
|
||
Comment 2•18 years ago
|
||
This seems to be fixed in trunk builds. It may be a dupe of bug 299065, but I'm not sure, so marking WORKSFORME.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
|
|
||
Comment 3•18 years ago
|
||
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a5pre) Gecko/20070516 Minefield/3.0a5pre
For me, trunk renders the page differently in that the image is below the <input> rather than beside it, so this sort of invalidates shafi's complaint that the horizontal order of the <input> and <img> is wrong...
|
|
||
Comment 4•18 years ago
|
||
Making the <table> wider prevents the image wrapping to the next line on trunk.
Attachment #265111 -
Attachment is obsolete: true
|
|
||
Comment 5•18 years ago
|
||
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a5pre) Gecko/20070516 Minefield/3.0a5pre
Thanks, Simon. Marking as VERIFIED.
Status: RESOLVED → VERIFIED
Thanks Adam, Simon for verifying this issue. I verified this works fine on the trunk.
But we have a limitation that we cant upgrade to FF3.0 as it might cause other issues in the framework level. I would like to know whether there is any possibility that this fix can be backported to Firefox 2.0.0.3?
Status: VERIFIED → UNCONFIRMED
Resolution: WORKSFORME → ---
|
|
||
Comment 7•18 years ago
|
||
In that case the first question has to be what fixed it. Can you find out when it started working? (See http://wiki.mozilla.org/MozillaQualityAssurance:Triage#How_to_Help_with_Regressions_--_Finding_Regression_Windows for tips on how to do this). However, the chances are low of drivers accepting a patch for 2.0.0.3 if it isn't a security issue. It may be more productive to look for a workaround in markup.
I started with the very first 2007-02-28-04-trunk/ and found that the bug is not reproducible from 2007-02-28-04-trunk onwards.
But I could reproduce the bug when I installed the one which is available under the folder '2.0.0.3-candidates/'.
I tried rc1,rc2,rc3 firefox builds under the folder '2.0.0.4-candidates/'. Even there I was able to reproduce this bug.
It seems this issue has been fixed on Minefield trunk before 28th Feb. But Firefox 2.0.0.4( as of 15th May) still has this problem.
|
||
Comment 9•17 years ago
|
||
Mass-assigning the new rtl keyword to RTL-related (see bug 349193).
Keywords: rtl
|
||
Comment 10•17 years ago
|
||
This was indeed fixed on trunk by the patch for bug 299065.
|
|
||
Updated•17 years ago
|
Status: NEW → RESOLVED
Closed: 18 years ago → 17 years ago
Resolution: --- → FIXED
Component: Layout: BiDi Hebrew & Arabic → Layout: Text
QA Contact: layout.bidi → layout.fonts-and-text
You need to log in
before you can comment on or make changes to this bug.
Description
•