Open Bug 1194844 Opened 9 years ago Updated 2 years ago

{inc} [RTL] XUL listbox doesn't reposition contents when resized, in RTL mode

Categories

(Core :: XUL, defect)

defect

Tracking

()

Tracking Status
firefox43 --- affected

People

(Reporter: dholbert, Unassigned)

References

Details

(Keywords: rtl)

Attachments

(2 files)

Attached file testcase 1
STR:
 0. Create about:config pref "dom.allow_XUL_XBL_for_file", set to true, so that you can load XUL directly.
 1. Download & load attached testcase.
 3. Reduce the width of your Firefox window.
 4. (optional) reload or scroll the listbox.

ACTUAL RESULTS:
 In step 3, the listbox's contents don't update their positions to stay in-view.  They're clipped (and eventually aren't visible at all) as the listbox shrinks.
 In step 4, when you scroll or reload, they pop back into view. (Scrolling doesn't actually help if you have APZ enabled, though, as Alice0775 White observed in bug 1194346 comment 7.)

EXPECTED RESULTS:
 Contents should stay visible when listbox is resized.

This seems to be an incremental layout bug.
Note: I can reproduce this at least as far back as Firefox 15. So, definitely not a recent regression (and possibly a bug that we've just had since forever).

However, we kind-of worked around it in builds before bug 1131371, if you had an item selected, because (if you've selected a listbox entry) the selection will lose & regain its 'outline' when you resize the window. Before bug 1131371, this happens to trigger a reflow, which makes the bug go away.
screencast of bug: attachment 8648188 [details]
Summary: {inc} XUL listbox doesn't reposition contents when resized, in RTL mode → {inc} [RTL] XUL listbox doesn't reposition contents when resized, in RTL mode
Keywords: rtl
Is one of the problems here that, if we fix the underlying problem it may break everyone else's workarounds? Hmm.
Nah, I don't think that's the case.  Fixing the underlying problem (in XUL/listbox layout) shouldn't break anything.

But: given that it's a long-standing problem (comment 1), and given that it's only exposed in an RTL + xul + resizing scenario (kinda edge-casey), and given that XUL is on its way out with browser.html on the horizon, it may end up being easier/more-efficient to just work around this issue in places where we hit it (e.g. bug 1194346) rather than to diagnose/fix it.
Here's a testcase with a HTML & XUL listbox side by side, demonstrating that we don't have this same problem for HTML listboxes.

However, on my sistem at least, the HTML listbox has a different problem :-/  There's a strip on the right side that doesn't get painted (so the final 1-2 characters are clipped, effectively).  I think this is us reserving some space for the scrollbar on the right side, at some level, despite the fact that the scrollbar is on the left.
(Yeah, the blank strip on the right is tracked in bug 1194851.)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: