Closed
Bug 1378065
Opened 7 years ago
Closed 3 years ago
Selected text with some Unicode characters can move up and down on pointer/mouse cursor movement
Categories
(Core :: Layout: Form Controls, defect, P3)
Tracking
()
VERIFIED
WORKSFORME
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 |
People
(Reporter: Virtual, Unassigned)
References
()
Details
(Keywords: nightly-community, regression)
Attachments
(1 file)
(deleted),
video/mp4
|
Details |
[Tracking Requested - why for this release]: Regression
STR:
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
Reporter | ||
Updated•7 years ago
|
Has STR: --- → yes
Updated•7 years ago
|
Component: Untriaged → Selection
Product: Firefox → Core
Comment 1•7 years ago
|
||
I can also reproduce the problem on Nightly56.0a1 Windows10.
Comment 2•7 years ago
|
||
Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5533bb0145694e5d8574909e4de66847ab84be8c&tochange=b7a6ec5eb1e1ff88d9ebc278de9ea3cd761f763f
Regressed by: b7a6ec5eb1e1 Masayuki Nakano β Bug 548311 Change Japanese default fonts only on early Beta and Nightly r=emk,jfkthame,m_kato
Updated•7 years ago
|
Component: Selection → Layout: Form Controls
Comment 3•7 years ago
|
||
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)
Comment 4•7 years ago
|
||
FWIW, it seems to me that Meiryo is constantly 1px shorter in Blink than in Gecko regardless of font-size.
Comment 5•7 years ago
|
||
Marking 55 disabled, as this font is only used in nightly and early beta (the next beta build this week will have that unset)
Reporter | ||
Updated•7 years ago
|
Has Regression Range: --- → yes
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.
Reporter | ||
Updated•7 years ago
|
QA Contact: Virtual
Reporter | ||
Updated•7 years ago
|
status-firefox57:
--- → affected
Updated•7 years ago
|
Reporter | ||
Updated•7 years ago
|
status-firefox57:
--- → fix-optional
Updated•7 years ago
|
Updated•7 years ago
|
Priority: -- → P3
Reporter | ||
Updated•7 years ago
|
Blocks: 1354004
status-firefox58:
--- → affected
Updated•7 years ago
|
Updated•7 years ago
|
Reporter | ||
Updated•7 years ago
|
status-firefox59:
--- → affected
Reporter | ||
Updated•7 years ago
|
Reporter | ||
Updated•7 years ago
|
status-firefox60:
--- → affected
Reporter | ||
Updated•7 years ago
|
status-firefox61:
--- → affected
Updated•7 years ago
|
Reporter | ||
Updated•7 years ago
|
status-firefox62:
--- → affected
Updated•6 years ago
|
Updated•6 years ago
|
status-firefox63:
--- → wontfix
status-firefox64:
--- → fix-optional
status-firefox-esr60:
--- → wontfix
Reporter | ||
Updated•6 years ago
|
status-firefox65:
--- → affected
Long standing regression,
I meant to say, we should stop triaging this and leave it to the component owner.
Reporter | ||
Updated•6 years ago
|
Comment 10•6 years ago
|
||
Bulk change for all regression bugs with status-firefox67 as 'fix-optional' to be marked 'affected' for status-firefox68.
status-firefox68:
--- → affected
Updated•6 years ago
|
Reporter | ||
Updated•5 years ago
|
Comment 11•5 years ago
|
||
[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
status-firefox69:
affected → ---
Comment 12•3 years ago
|
||
I couldn't manage to reproduce this issue. Closing this bug as resolved: Worksforme.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 13•3 years ago
|
||
The issue does not occur anymore on Mozilla Firefox 96.0a1 (2021-11-04), so I am closing this issue as WORKSFORME.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•