STR: 1) Using the latest Swype Beta, go to AwesomeScreen, swype "hello". 2) Try to swype "bob" Expected results: "hellobob" appears. Actual results: The results are inconsistent, but I've seen things like "hellohello", "helloHellboy", and "helloballoon" appear. It seems as if the first Swyped word is somehow getting combined with the second. Other STR: 1) Swype "Google" 2) Swype ".com" You'd expect to see "Google.com", but it always comes out as "GoogleGoogle.com". The stock browser does not have this problem.
I suspect this is a problem with our IME being confused by Swype spell correction.
blocking-fennec1.0? This bug should probably be a .N+ blocker.
(In reply to Chris Peterson (:cpeterson) from comment #2) > blocking-fennec1.0? This bug should probably be a .N+ blocker. Do we have any idea what swype's release schedule is? Will this become their production keyboard before 15 goes out?
(In reply to Brad Lassey [:blassey] from comment #3) > Do we have any idea what swype's release schedule is? Will this become their > production keyboard before 15 goes out? I think we must treat Swype betas as "real" releases because, I AFAICT, Swype has never released a downloadable non-beta build. I think their non-beta releases are pre-installed on devices and updated at the device OEM's discretion (i.e. not very often). Brian is using Swype Beta 22.214.171.12409, but I am using Swype Beta 3.26.92D.39062.t0.10977.ENSP. (phew!) Confusingly, the Swype forums confirm that version 1.0 will supersede version 3.26.
Swype confirmed on their forums that they have no plans to release a non-beta version of Swype to the Google Play store. So all manually-installed beta builds are "real" releases, but most Swype users will probably be using a pre-installed version from their device OEM. > Regarding the Swype Beta program, it is a perpetual beta - this means we have no plans > to end this beta program and we will continue it indefinitely. We have no plans to > release the full version of Swype in the Google Play store or any other app store. Our > business model is to work with OEMs towards having Swype pre-loaded onto their devices. > The Swype Beta program is a sort of 'parallel track' to our OEM release cycle. http://forum.swype.com/showthread.php?6470-What-After-Beta&p=28383#post28383
Chris - Any update here? Can you loop in Brian so we can try to make some headway next week?
Brian, can you still repro this bug? I am no longer able to reproduce it using Swype Beta 126.96.36.19909. If you have an older version of Swype Beta, try to reproduce this bug BEFORE (and then after) updating Swype! If this bug is still reproducible, I suspect Swype's spell correction is causing the problem. After you swype "hello" and start to swype "bob", Swype probably still remembers "hello" and spell corrects "hellobob" to "Hellboy" or "balloon". We then append "Hellboy" or "balloon" to our existing "hello" string.
Confirming that non-password masked fields are affected too; simply used Google Search field and SUMO's Ask a Question field.
I cannot repro either using the latest Swype Beta 188.8.131.5209 on Galaxy Nexus Aaronmt, which version did you use?
I can still repro on a Droid RAZR with Swype Beta 184.108.40.20609.
I can no longer repro on Fennec (or ICS stock browser), but I *can* repro on Chrome. So this may be a Swype Beta bug, but maybe we can find a workaround until Swype fixes it.
Since this is Swype Beta's bug, it should be safe to assume they'll fix it before releasing it to OEM. I don't think it's worth spending time fixing their bug for a beta, especially when users can only get it by going to Swype's website and downloading it outside of the market.
This is still something that we could potentially harden against. However, this new information leads me to think this does not need to block 14.0.1
WFM for Beta 15, Aurora 16, and Nightly 17 with Swype Beta 220.127.116.1109 on Galaxy Nexus. I think my fix for bug 767597 fixed this bug. Firefox 14 is still busted. Chrome 18 is still busted, too. <:)