32441 - html form data is inconsistently lost when xml is sorted

Status: RESOLVED INVALID

(Core :: Layout: Form Controls, defect, P1)

Description

[rwoods]

The URL above adds the following html form to each book in the Mozilla XML
Sorting demo (most books deleted for brevity):
<Book>
...
   	<html:form>
		<html:input type="text" name="power">
		</html:input>
	</html:form>
</Book>

When data is entered into the resulting form fields, sorting or toggling
inconsistently loses the entered data.

This is Mozilla/m14-FC (this apparently contradicts user-agent initialized
field). Build ID 2000022414

Comment 1

[Adam]

The form data gets lost when changing style or switching to a different sorting
mech and then back. Something doesn't seem right about this bug/test but I'm too
tired to think right now. rwoods - can you attach the testcase to this bug?

Comment 2

[rwoods]

Attachment: testcase demonstrating bug

Comment 3

[rwoods]

Three new pieces of information:
1. Putting data in the form fields and then toggling the style repeatedly will
usually crash the browser, sometimes interfering with correct layout on the
toggle prior to the crash.
2. Putting data in the form fields, moving to a new URL and then returning to
the page using the Back button also loses the data.
3. Substituting popup menus for the fields also results in analogous loss of the
selected menu value.

Comment 4

[rwoods]

The following Macsbug output was obtained by loading the previously attached
testcase and doing the following:
1. Enter 'x' in both fields.
2. Press 'Toggle Style'
3. Enter 'x' in both fields again (original 'x's disappeared).
4. Press 'Toggle Style' again.

PowerPC access exception at 182C0D48 PR_Lock+00094
 Calling chain using A6/R1 links
  Back chain  ISA  Caller
  00000000    PPC  182286F8
  082E3800    PPC  18217A18  main+0016C
  082E3770    PPC  18217360  main1(int, char**, nsISplashScreen*)+0061C
  082E3670    PPC  17D9A1D4  nsAppShellService::Run()+9A1D4
  082E3630    PPC  17CFCEAC  nsAppShell::Run()+00038
  082E35E0    PPC  17CFD5CC  nsMacMessagePump::DoMessagePump()+0003C
  082E3590    PPC  17CFD8A0  nsMacMessagePump::DispatchEvent(int,
EventRecord*)+00174
  082E3540    PPC  18079874  Repeater::DoRepeaters(const EventRecord&)+00030
  082E3500    PPC  1807A514  TimerPeriodical::RepeatAction(const EventRecord&)+00048
  082E34B0    PPC  1807A06C  TimerImpl::Fire()+00024
  082E3470    PPC  17DE5798  nsGlobalWindow_RunTimeout(nsITimer*, void*)+00018
  082E3430    PPC  17DE4EB0  GlobalWindowImpl::RunTimeout(nsTimeoutImpl*)+002AC
  082E31D0    PPC  17DC8FB0  nsJSContext::CallEventHandler(void*, void*,
unsigned int, void*,
 int*)+001F0
  082E3110    PPC  18247384  JS_CallFunctionValue+00028
  082E30D0    PPC  1826025C  js_InternalInvoke+000C0
  082E3010    PPC  18260028  js_Invoke+00564
  082E2F20    PPC  18265DD0  js_Interpret+0532C
  082E2D20    PPC  18270330  js_SetProperty+007A8
  082E2C70    PPC  18268C6C  js_LockObj+0002C
  082E2C20    PPC  18268ACC  js_LockScope1+00040

Comment 5

[rods (gone)]

Please attach all the necessary style sheets for the attached testcase.
Thanks.

Comment 6

[rwoods]

Attachment: First of three style sheets for testcase

Comment 7

[rwoods]

Attachment: Second of three style sheets for testcase

Comment 8

[rwoods]

Attachment: Third of three style sheets for testcase

Comment 9

[rwoods]

Attachment: Revised test case referencing attached style sheets

Comment 10

[rwoods]

Attachment: Revised testcase that correctly pulls style sheets

Comment 11

[rwoods]

Explanation of attached testcases id=6726, id=7171 and id=7172:
All three are identical except for the source of style sheets:
id=6726 uses the original style sheets from
"http://www.mozilla.org/newlayout/xml/books/"
id=7171 uses style sheets defined locally called common.css, classic.css and
list.css
id=7172 used style sheets from "http://bugzilla.mozilla.org/show_bug.cgi?id="
where id=7168, 7169 and 7170

Comment 12

[rods (gone)]

mass-move to M16

Comment 13

[rickg]

Data loss is bad; upping the priority.

Comment 14

[rods (gone)]

work for me

Comment 15

[rwoods]

Although the data loss is now gone, I still reproducibly crash my machine by
doing the following:
1. Place 'x' in both fields
2. Press toggle style
3. Place another 'x' in both fields
4. Press toggle style

This is with the latest nightly build ID=2000042808

Comment 16

[rods (gone)]

I click to my heart's content and it doesn't crash on WinNT.

Waqar, could you check this out on the Mac?

add waqar to the cc'list

Comment 17

[rods (gone)]

reassigning

Comment 18

[waqar]

investigating

Comment 19

[Adam]

I'm still seeing data loss from the original URL testcase (haven't tried others - 

Moz keeps crashing).



Mozilla M16 2000051108, Mac OS 9.0.4.

Comment 20

[ekrock's old account (dead)]

Crash & data loss both bad. nsbeta2.

Comment 21

[Adam]

ekrock - I had a chance to test this out using the 05.20.2000-20 build, Mac OS

9.0.4. The crashing I was referring to in my earlier comment was just about

general instability in that night's build so I couldn't fully test the bug. But

I was, and still am seeing data loss when sorting. There is no crashing (AFAIK)

that is related to this bug.

Comment 22

[rods (gone)]

What data is being lost?

Comment 23

[rwoods]

Per Eric Krock's request, I have just re-reported the still unresolved crashing 
issue separately as bug 40231. Unlike Adam Kay, I have not seen the data loss 
(which prompted this original bug report) since April. However, I do still find 
that upon visiting some other page and then returning to the test case using the 
back button loses any data previously entered in the test case form. Perhaps this 
is the data loss that Adam Kay is still experiencing?

Comment 24

[rwoods]

The problem with form data disappearing when returning to the form using the
back button appears to be a generic problem unrelated to the xml sorting issue
originally reported in this bug. For clarity, I have now reported this issue
separately as bug 40515.

Comment 25

[leger]

marking this bug invalid.

Comment 26

[bsharma]

Updating QA contact.