Closed Bug 1378065 Opened 5 years ago Closed 10 months ago

Selected text with some Unicode characters can move up and down on pointer/mouse cursor movement


(Core :: Layout: Form Controls, defect, P3)

55 Branch
Windows 7



Tracking Status
firefox-esr60 --- wontfix
firefox54 --- unaffected
firefox55 - disabled
firefox56 - disabled
firefox57 --- wontfix
firefox58 --- wontfix
firefox59 --- wontfix
firefox60 --- wontfix
firefox61 --- wontfix
firefox62 --- wontfix
firefox63 --- wontfix
firefox64 --- wontfix
firefox65 --- wontfix
firefox66 --- wontfix
firefox67 --- wontfix
firefox67.0.1 --- wontfix
firefox68 --- wontfix


(Reporter: Virtual, Unassigned)




(Keywords: nightly-community, regression)


(1 file)

Attached video screencast.mp4
[Tracking Requested - why for this release]: Regression

1. Paste this text
> 初音ミクがオリジナルを歌ってくれたよ「ブラック★ロックシューター」
into address bar, search bar, find bar, bookmark doorhanger/panelUI, Library, etc. and even on website pages, it happens on all 1 line areas where you can paste some test
2. Select some part of the pasted text
3. While keeping selection, move pointer/mouse cursor up and down few times
and see that text also going up and down
Component: Untriaged → Selection
Product: Firefox → Core
I can also reproduce the problem on Nightly56.0a1 Windows10.
Regression window:

Regressed by: b7a6ec5eb1e1	Masayuki Nakano — Bug 548311 Change Japanese default fonts only on early Beta and Nightly r=emk,jfkthame,m_kato
Blocks: 548311
Flags: needinfo?(masayuki)
Component: Selection → Layout: Form Controls
Looks like it's line-height issue of <input> element because Meiryo's default line-height is higher than other fonts'.

If we'd increase height of <input> element, it could cause breaking some websites' layout. Also, we could use |overflow-y: hidden;| for the anonymous <div> in <input> element but even if we could do that, it's really risky for other languages. E.g., I worry about Devanagari (IIRC, some South-Asian characters require higher space than usual).

Other possible scenario is, we hack metrics of Meiryo. As far as I know, the computation of normal line-height is different from Blink. Our line-height is higher than them and it causes unexpected overflow. (Although I saw it only in a website and I reported that to the company directly.)

Fortunately, underscore is not hidden by this bug. So, not so important issue. Although I don't like this kind of bug.
Flags: needinfo?(masayuki)
FWIW, it seems to me that Meiryo is constantly 1px shorter in Blink than in Gecko regardless of font-size.
Marking 55 disabled, as this font is only used in nightly and early beta (the next beta build this week will have that unset)
Looks like Masayuki is aware of the regression and considers it minor. 
So I don't think release management needs to track this bug. It would be nice to fix it since we have STR, though.
Priority: -- → P3
See Also: → 1406148
I meant to say, we should stop triaging this and leave it to the component owner.

Bulk change for all regression bugs with status-firefox67 as 'fix-optional' to be marked 'affected' for status-firefox68.

[bulk change 69 status -> --- b/c to stop re-triaging old regressions every release]

Triage Owners: please do not set release status tracking flags in new releases unless this bug will actually be worked on

I couldn't manage to reproduce this issue. Closing this bug as resolved: Worksforme.

Closed: 10 months ago
Resolution: --- → WORKSFORME

The issue does not occur anymore on Mozilla Firefox 96.0a1 (2021-11-04), so I am closing this issue as WORKSFORME.

You need to log in before you can comment on or make changes to this bug.