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.
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).
See the URL field for a testcase.
Created attachment 504668 [details] Screenshot 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...
Created attachment 505107 [details] [diff] [review] Patch v1 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).
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.
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...
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.