* TITLE/SUMMARY [PP] On URL text field update, cursor moves to beginning of field * STEPS TO REPRODUCE 0) Launch Apprunner 1) Type a URL (say, www.mozilla.org), and press return 2) After the page has finished drawing, append "foo" to the URL, and press return. * RESULT - What happened After step #1, the cursor relocates from the end of the text field to the beginning of the text field when the text field is updated (from www.mozilla.org to http://www.mozilla.org/) After step #2, the cursor relocates (as in step #1) upon pressing return - What was expected Behavior consistent with other platforms; text cursor shouldn't relocate itself unexpectedly. * REGRESSION - Occurs On Win32 Apprunner (7.1.99 AM optimized build [NT 4, Service Pack 3]) - Doesn't Occur On Linux, Mac OS Apprunner (7.1.99 AM optimized build) (Chris Pratt couldn't reproduce on Win98, either.) * CONFIGURATIONS TESTED - [Mac] Power Mac 8500/120 (233 Mhz 604e), 64 MB RAM (VM on; 1 MB of VM used), 1024x768 (Thousands of Colors), Mac OS 8.6 - [Win32] Vectra VL (233 Mhz P2), 96 MB RAM, 800x600 (True Color), NT 4.0 SP3. - [Linux] Vectra VL (266 Mhz P2), 96 MB RAM.

[I believe this is a native widget, and XP Toolkit/Widgets is the wrong component. However, I suspect Peter will know where this should go; the component page didn't.]

[QA Assigning to self, if that's okay with phillip.] And, yes, Chris was running the same build on Win98, so, this is NT-specific.

I don't think we'll be fixing any further native text widget bugs. Reassigning to don in case it is an XPApps problem, if not, it could go to Ender to ensure that we don't have this problem after flipping the GFX switch.

Radha, is this a bug or a feature?

Changing component to Editor to make sure this doesn't happen in gfx widgets

Reassigned to buster, to make sure this is taken care in gfx widgets

with gfx text controls, I believe this works correctly on all platforms. qa, please verify

QA Assigning to self, as nobody had this bug.

As a result of replacing the native widgets with GFX widgets, this has been fixed. While it was only a problem specific to native Win32 widgets, I did confirm on all 3 platforms in current builds to be sure. (Checked Win32: 1999111014, Mac OS: 1999110913, Linux: 1999111008.) Thus, re-opening to verify as FIXED.