Closed
Bug 69397
Opened 24 years ago
Closed 24 years ago
strings in document trashed or changed
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
People
(Reporter: alex.dent, Assigned: jst)
References
()
Details
(Keywords: dom2)
Attachments
(4 files)
go to the url, and select one of the items in "agenturen" (sorry, german page),
this is the second menu on the left. in this area there is a form in the middle
left block, with 2 radio buttons. sometimes there will be part of the form tag
source visible, or the form will not appear at all (select some different items
in "agenturen" if the bug doesn´t immediately appear).
i have at least one other page in production that shows the same kind of bug,
but there it is not related to a tag or entitiy but appears in the middle of the
text, changing or dropping letters (btw, cremefraichedigit.com is a 401/loose
document, the second page (not finished yet, can´t show it) is 401/strict, both
sites use frames and a lot of scripting between the frames). this will only
happen sometimes, but then always at the same place and with only a few
different types of changes, not something random. i could imagine some strange
string concatenation problems that happen when you use a lot of strings and
string fragments, don´t know exactly how this is handled by the engine.
the pages are created completely on the fly with js and no other browser (works
in netscape 4, and ie4 + 5) shows this kind of bug. it doesn´t matter how i
configure the cache or what skin i use. the html for the elements is created
using a range object and createContextualFragment, not innerHTML. if i get the
innerHTML of the div where the bugs are, it shows the source that matches the
output, but not the html that should be there.
because this bug is so special i have not yet been able to create a simple
testcase :-( but i know that it worked always in a build from jan 22, and every
earlier release, including the branch builds. i don´t know exactly when it
began, but a build from jan 30 has already shown this bug.
i think this is a major bug because it shows a major design flaw in mozillas
code (and could create much more serious problems), although it happens only in
special cases.
Comment 1•24 years ago
|
||
Alex, what build are you currently using? I cannot reproduce this bug on Linux
using 2001-02-19-08. Is this MacOS only? Or is this fixed in the newest builds
for you too?
i just downloaded and tested build 2001021908, and it has the bug. this is macos
8.6, virtual memory on. the bug doesn´t always appear. sometimes you need to
switch up to 10 times to other items in the "agenturen" menu before it happens,
sometimes on the first try. it could be a mac only bug, maybe this explains why
the bug was there so long, because there are not that many mac users...
can someone verify this on mac? or any other os?
OS: Mac System 8.5 → Mac System 8.6
Updated•24 years ago
|
Component: DOM Level 2 → DOM HTML
i have done some further research with build 2001022209 in win98. the bug is
there, but it is *much* harder to trigger, takes like 15 - 30 trials.
also i have noted that this bug affects only two bytes at a time (both win and
mac), either removing or inserting them, sometimes with strange results if the
bytes are part of a tag or entity.
| Assignee | ||
Comment 4•24 years ago
|
||
I tried this on windows with a build from monday, could you please retest, do
you see this on Mac only? Can you test on other systems?
Comment 5•24 years ago
|
||
Adding self and bhart to CC. Bradly, could you please test this bug? (If you
don't want to be CC'ed for testing anymore just drop me a note, but you're like
the only mac user that I know of :)
i have made a very simple test case, it repeats the word "test" a few hundred
times, and if the alignment on the right border isn´t exactly the same in every
line, you see the bug. i have tested this with mac build 2001022808 and win
build 2001022805, both show the bug.
remember that you have to reload the page a few (1 - 20) times before this will
happen, don´t know why.
| Reporter | ||
Comment 10•24 years ago
|
||
the testcase above shows the bug in an alert. it seems that this is rather a bug
in the script engine than in the dom, but i really don´t know anything about how
these things are related.
Comment 11•24 years ago
|
||
I'm seeing this in the testcases, marking NEW (Mac OS 8.6 build 2001022714).
This is really wierd.
Status: UNCONFIRMED → NEW
Ever confirmed: true
| Assignee | ||
Comment 12•24 years ago
|
||
I just tried the testcase on a mac and I loaded it more than 50 times and I did
not see the problem, I also tried it on windows and same thing, no problems. I'm
clueless. Could someone provide more info, connection speed, computer setup,
something? Anything?
| Assignee | ||
Comment 13•24 years ago
|
||
When you do see the bug in the alert box, do you also see missing characters in
the document window? What if you run the testcase until you see the bug in the
alert() and click Ok in the alert box and then type "javascript:window.bug();"
in the URL bar (without the quotes), you should see the alert again, do you see
the bug in the alert then too?
| Reporter | ||
Comment 14•24 years ago
|
||
i use macos 8.6, virtual memory on, mozilla set to 20 mb (default); and win 98
in vpc3 with 127 mb for win. everything is set to default, this is a test
machine. i have tried different cache settings and themes, doesn´t have any
effect. tried from local hd, local network and internet, no effect.
if i get the bug in the alert i get it in the document as well, and when i call
bug() again it is the same string.
it is also possible to enter "javascript:alert('long string');" and it will
sometimes show the bug. test it with the string in the test cases, works for me.
the interesting thing is that i leave the string in the url input and just hit
return again, and it will show different results. haven´t tried this in windows.
| Reporter | ||
Comment 15•24 years ago
|
||
the shortest string i have seen with this bug was 506 chars long. under 500
seems save. concatenating several smaller strings to a long string does not show
the bug.
| Assignee | ||
Comment 16•24 years ago
|
||
Sounds like this really could be a JS engine problem, cc:ing brendan so that
he's aware of this hard to reproduce weirdnes.
| Reporter | ||
Comment 17•24 years ago
|
||
| Reporter | ||
Comment 18•24 years ago
|
||
maybe this is not related to this bug, but i tried what happens if i take a
string from the dom. so i put the test string in the div and alerted the
innerHTML, and it is different. just some spaces are missing, no changes or
anything more complicated. this happens only on mac, not win. in windows the
layout of the two alerts is really messed up (in mac too, but not so weird), not
showing the ok button and with strange linebreaks.
i guess this is another bug, maybe already known?
Comment 19•24 years ago
|
||
[really cc'ing brendan]
Comment 20•24 years ago
|
||
I know of no such bug in the JS engine. I do not see this on my last-night's
Linux optimized build. If this bug could be made more easily reproducible, then
we could lay a trap in the debugger, or with ad-hoc debugging code. We'd have
to narrow things down a bit, so reproducibility is the first order of business.
/be
Comment 21•24 years ago
|
||
Compare new bug 72034 : "JS_ArenaRealloc assumes realloc preserves alignment"
Comment 22•24 years ago
|
||
*Now* I know of such a bug -- sorry I didn't dig deeper. Duping against 72034,
which has the fix-patch.
/be
*** This bug has been marked as a duplicate of 72034 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•