Closed
Bug 626605
Opened 14 years ago
Closed 14 years ago
Arrow panels behave randomly when in RTL mode
Categories
(Core :: XUL, defect)
Core
XUL
Tracking
()
RESOLVED
FIXED
mozilla2.0b10
Tracking | Status | |
---|---|---|
blocking2.0 | --- | final+ |
People
(Reporter: mounir, Assigned: mounir)
References
()
Details
(Keywords: rtl)
Attachments
(2 files)
66.52 KB,
image/png
|
Details | |
2.18 KB,
patch
|
enndeakin
:
review+
|
Details | Diff | Splinter Review |
As far as I've tested, depending on where the arrow points, the behavior is different. If it points to the middle of the anchor, it seems to currently work fine but if it points to an edge (right/left), it doesn't.
Assignee | ||
Comment 1•14 years ago
|
||
IMO, this should block because it's a big issue when in RTL mode and it's a follow-up from a blocking bug (ie. bug 619223 isn't fully fixed).
blocking2.0: --- → ?
Keywords: rtl
Assignee | ||
Comment 2•14 years ago
|
||
See the URL field for a testcase.
Assignee | ||
Comment 3•14 years ago
|
||
I actually realize that it might not be related to center or net given that these screenshots have been taken with the arrow not contered on checkboxes...
Assignee | ||
Comment 4•14 years ago
|
||
The current code doesn't take into account popups at the right of the anchor and situations were it's hard to say if the popup is at the right or at the left.
IMO, the best solution would be to keep aPosition passed to openPopup because that really reflects were the arrow should be. Here, we have to guess depending on how the popup is positioned (given that it's positioned depending on where the arrow should be). It seems weird and can't be 100% correct.
However, because I assume there were reasons to do that that way, this patch doesn't keep aPosition and is just guessing where the arrow should be. At least, it should be more correct that the current code (I hope).
Assignee: nobody → mounir.lamouri
Status: NEW → ASSIGNED
Attachment #505107 -
Flags: review?(enndeakin)
Assignee | ||
Updated•14 years ago
|
Whiteboard: [needs review]
Comment 5•14 years ago
|
||
Comment on attachment 505107 [details] [diff] [review]
Patch v1
This looks like it would be better. I'm not sure if we really want the checks that divide the width in half. It seems there are cases where that could compute to an arrow that sticks off the edge, but we can revisit that later.
Attachment #505107 -
Flags: review?(enndeakin) → review+
Assignee | ||
Updated•14 years ago
|
Attachment #505107 -
Flags: approval2.0?
Assignee | ||
Updated•14 years ago
|
Whiteboard: [needs review] → [needs approval]
Comment 6•14 years ago
|
||
I think we want this patch for RTL support (well, I'd block on it in fact), but I'm CCing a bunch of people begging for approval...
blocking2.0: ? → final+
Assignee | ||
Updated•14 years ago
|
Whiteboard: [needs approval] → [needs landing]
Assignee | ||
Updated•14 years ago
|
Attachment #505107 -
Flags: approval2.0?
Comment 7•14 years ago
|
||
I agree that this issue is blocking for rtl.
Mounir's patch seems fine. Nevertheless, I wonder why the arrow shouldn't be always centered at the leftside (or rightside for rtl) of the input field.
Assignee | ||
Comment 8•14 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing]
Target Milestone: --- → mozilla2.0b10
You need to log in
before you can comment on or make changes to this bug.
Description
•