When I fixed bug 288789 by changing the semantics of nsFrameList::GetPrev[Next]VisualFor(), I neglected to change the case where the parent frame is not a block frame (i.e. it's an inline frame). This has no effect on textareas (which can't contain inlines), but it does break HTML editing, keyboard-selection, and caret navigation when bidirectional text is contained within an inline element. I'll attach a testcase and a patch soon.
Created attachment 200231 [details] testcase In Composer, or Caret Browsing mode: In the upper paragraph, try moving the caret in and out of the numbers (in the 1st and 3rd lines). Notice that the caret moves to all kinds of unexpected places. The lower paragraph (which is idetical except it is not wrapping a <span>) works correctly.
Created attachment 200233 [details] [diff] [review] patch In the case where the parent is not a block frame, use the direction-aware nsFrameOrigin (with a dummy value of "0" for the line number), instead of just comparing the x coordinates (disregarding direction). Simon - do you think you can review this soon so we will have some sort of chance of getting this into 1.8? (I'm not too optimistic, but let's try).
Comment on attachment 200233 [details] [diff] [review] patch r=smontagu
Comment on attachment 200233 [details] [diff] [review] patch Thanks, Simon! ROC - same request here. This is a regression, and I'd really like to try and slip the fix into 1.5.
Comment on attachment 200233 [details] [diff] [review] patch looks good ... it's pretty clear that nothing has changed for LTR too
Comment on attachment 200233 [details] [diff] [review] patch Asking for last-minute approval1.8rc1. The changed code is only reached when navigating in bidi HTML, so any risk is limited to that area (which is pretty broken without this fix).
not going to flag this as a blocker but if it lands before the freeze, then it's in :-)
Checked in by timeless to both trunk and branch, 2005-10-21, 13:06.