Closed
Bug 735864
Opened 13 years ago
Closed 13 years ago
Password fields with partial SKB does not show any input in portrait (partial VKB) mode
Categories
(Core :: General, defect)
Tracking
()
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
blocking-fennec1.0 | --- | + |
People
(Reporter: nhirata, Unassigned)
References
()
Details
(Keywords: regression)
1. go to http://people.mozilla.com/~nhirata/html_tp/NextAction_Bug614356.html
2. click in the Password field in portrait mode
3. type "something"
Expected: "*********"
Actual: nothing seems to happen
Note:
1. placing the device in landscape will show asterisk symbols
2. using tinderbox build : http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla-central-android/1331738369/
Reporter | ||
Updated•13 years ago
|
Component: General → IME
QA Contact: general → ime
Comment 1•13 years ago
|
||
Is this a regression?
Comment 2•13 years ago
|
||
I suspect this is a maple regression. If you pinch-zoom a little, the page will re-render and display the password asterisks correctly.
When I tap focus to the Password field on my Samsung S2, the page switches to a blank grey color.
When I tap focus to the Password field on my Galaxy Nexus, the page appearance does not change and does not update when I type.
Keywords: regression
Comment 3•13 years ago
|
||
Nominating because this blocks a fennec1.0 blocker (bug 707353).
blocking-fennec1.0: --- → ?
Updated•13 years ago
|
Component: IME → General
Product: Fennec Native → Core
QA Contact: ime → general
Version: Firefox 14 → Trunk
Updated•13 years ago
|
blocking-fennec1.0: ? → +
Updated•13 years ago
|
Whiteboard: [gfx]
Comment 4•13 years ago
|
||
We should retest this once bug 728983 is fixed; we have invalidation issues already, and this seems like another.
Depends on: 728983
Whiteboard: [gfx]
Comment 6•13 years ago
|
||
Time to retest. I can't replicate on Galaxy Nexus with the 728983 fix.
Keywords: qawanted
Reporter | ||
Comment 7•13 years ago
|
||
I can't seem to reproduce this on the Samsung S II with today's nightly.
Having said that, I tried testing out the next button and I ran into an issue where I could not see what I was typing after hitting next (in the two input elements section)
Should we close this one and open a new one?
Reporter | ||
Comment 8•13 years ago
|
||
To note: in comment 7, it seems to be a refresh issue. After I hit the home button and go back into Fennec, I can see what I typed.
Comment 9•13 years ago
|
||
Now that bug 732016 is fixed, this has changed into bug 747845.
Reporter | ||
Comment 10•13 years ago
|
||
Clearing the qawanted; this bug is no longer happening. Text input is showing different issues. See bug 747680
Renoming to clear this from the blocking fennec list.
blocking-fennec1.0: + → ?
Keywords: qawanted
Comment 11•13 years ago
|
||
We have backed out 732016 on inbound. Joe has builds, we need to retest if this is dependent on 732016 or not.
Keywords: qawanted
Reporter | ||
Comment 12•13 years ago
|
||
I don't see this bug anymore, but I am seeing a but in regards to not seeing anything being typed after hitting the next button. bug 748048
Reporter | ||
Comment 13•13 years ago
|
||
Resolving as WFM.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Updated•13 years ago
|
blocking-fennec1.0: ? → +
You need to log in
before you can comment on or make changes to this bug.
Description
•