Fallback on facebook in XULTextBox caused by <input type=file>

NEW
Unassigned

Status

()

defect
P2
normal
2 years ago
Last year

People

(Reporter: jrmuizel, Unassigned)

Tracking

(Blocks 2 bugs)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [wr-reserve])

Attachments

(1 attachment)

Flags: needinfo?(emilio)
Whiteboard: [wr-mvp] [triage]
Priority: -- → P3
Whiteboard: [wr-mvp] [triage] → [wr-mvp] [triage][wr-reserve-candidate]
Whiteboard: [wr-mvp] [triage][wr-reserve-candidate] → [wr-reserve]
So I gave this a try, and it looks nice except for a tiny thing (actually not so tiny...).

Worst part is, we actually re-reflow (an repaint?) when creating the label, .

That label is given a crop="center" attribute. That means that when the content overflows the text area, we crop in the middle of the file instead of in to the right, that is, if I upload mysuperlongfile.txt, and it doesn't fit, the label renders my...file.txt.

Chrome does it in special painting code[1]. We do it on nsTextBoxFrame[2], which is obviously the thing we're trying to kill...

So here's the question... Jeff, do you think it is doable / worth to override the nsFileControlFrame so that it creates a display list so that the text is cropped to the center or what not? Alternatively, we may get away with regressing this crop to center thing, but that's not great...

[1]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/paint/FileUploadControlPainter.cpp?l=46&rcl=0d3eb1e182a841e43ec018cc68a176f813d66d24
[2]: https://searchfox.org/mozilla-central/rev/9f3bd430c2b132c86c46126a0548661de876799a/layout/xul/nsTextBoxFrame.cpp#756
Flags: needinfo?(emilio) → needinfo?(jmuizelaar)
 (In reply to Emilio Cobos Álvarez [:emilio] from comment #3)
> So I gave this a try, and it looks nice except for a tiny thing (actually
> not so tiny...).
> 
> Worst part is, we actually re-reflow (an repaint?) when creating the label, .

Err, I forgot to fill this part. Anyway, you can imagine... We load the binding, post a reflow callback and all the stuff, then when we arrive there end up painting the cropped value.
If the patch in bug 1413271 fixes this, maybe we don't even need to worry about anything here. I don't know how much the extra reflow matters if it only happens on pages with file inputs, and in any case, that part is not a webrender regression.
Unfortunately, I don't feel equipped to really make any kind of call on what we should do here.
Flags: needinfo?(jmuizelaar)
I don't think this needs to block release.
No longer blocks: stage-wr-nightly
fixed? (xul text should be native now)
Flags: needinfo?(jmuizelaar)
The text seems fixed but I still see a red highlight on the Browse button on the file upload field on https://bugzilla.mozilla.org/attachment.cgi?bugid=1421382&action=enter
Flags: needinfo?(jmuizelaar)
You need to log in before you can comment on or make changes to this bug.