Get rid of SIP button on windows mobile

RESOLVED FIXED

Status

()

Core
Widget: Win32
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: blassey, Assigned: blassey)

Tracking

({mobile})

Trunk
ARM
Windows Mobile 6 Professional
mobile
Points:
---
Bug Flags:
wanted-fennec1.0 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 3 obsolete attachments)

The SIP button is way to ugly because we don't have softkeys.  Madhava decided we should get rid of it and just loose the functionality.
Flags: wanted-fennec1.0+
Created attachment 385443 [details] [diff] [review]
Always call ShowWindow(hWndSIP, SW_HIDE)
Attachment #385443 - Flags: review?(doug.turner)

Comment 2

9 years ago
Comment on attachment 385443 [details] [diff] [review]
Always call ShowWindow(hWndSIP, SW_HIDE)

I do not think I understand this.

when I click in a text box, a software keyboard provided by a 3rd party or MS appears.  What this patch does is just makes it impossible to switch between these keyboards.

how about we:

1) make this a pref so that power users could rename it
2) reposition the keyboard so that it takes up the space where the SIP button was (eg. move the keyboard window down by the height of the SIP button.
Attachment #385443 - Flags: review?(doug.turner) → review-
Created attachment 386204 [details] [diff] [review]
patch v.2
Attachment #386204 - Flags: review?(doug.turner)
In an effort to be consistent with existing prefs, could you use:

ui.showSIPButton

If we think we will have more SIP (windows, maemo or other platforms) we could use:

ui.sip.showButton

where we could use "sip" (software input panel) to mean "software keyboard"

Comment 5

9 years ago
Comment on attachment 386204 [details] [diff] [review]
patch v.2

create a static variable that gets set instead of checking for the pref every time we activate (similar to what we do for painting -- see  sRenderMode)

what finkle said too.

what is the behavior if hWndSIPB or hWndSIP are null and you make it into the block where "showSIPButton != PR_TRUE"?  Maybe we should just return early if either are null?
Attachment #386204 - Flags: review?(doug.turner) → review-
Created attachment 386389 [details] [diff] [review]
patch v.3
Assignee: nobody → bugmail
Attachment #385443 - Attachment is obsolete: true
Attachment #386204 - Attachment is obsolete: true
Attachment #386389 - Flags: review?(doug.turner)
Created attachment 386396 [details] [diff] [review]
patch v.4

fixed logic
Attachment #386389 - Attachment is obsolete: true
Attachment #386396 - Flags: review?(doug.turner)
Attachment #386389 - Flags: review?(doug.turner)

Updated

9 years ago
Attachment #386396 - Flags: review?(doug.turner) → review+
pushed http://hg.mozilla.org/mozilla-central/rev/2c4c63849e9f
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
(Assignee)

Updated

9 years ago
Duplicate of this bug: 489426
You need to log in before you can comment on or make changes to this bug.