Rendered position disagrees with style after threads change style

RESOLVED INCOMPLETE

Status

()

RESOLVED INCOMPLETE
17 years ago
10 years ago

People

(Reporter: Kanef, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

17 years ago
Build id:  20011112011 (Mozilla 0.9.6)

At the above URL, you'll find two HTML files that are almost identical.
   bug-shows-up.html 
   bug-does-not-show-up.html 
One shows this bug and the other doesn't.
The only difference is that one file has some additional planet images added
(not draggable, to simplify this test case).

Try the following in each file.

  1.  Drag Earth down (below the nebula).
  2.  Drag Mars down.  (The two will change size; you can wait or not.)
  3.  Drag Earth back up (above the nebula).
  4.  Repeat one or more times:  Drag Earth down, drag Earth up.

It's timing dependent, but not very.
There's a >>75% probability of triggering the bug right on the first repetition
of step 4 in the one, and I've never seen it happen in the other.

Correct behavior:  Earth shrinks in place.

Incorrect behavior:  After it finishes shrinking, it suddenly jumps back down to
its previous location below the nebula.  If you look at its style.top, it will
reflect the place you put it (a number below 200; you can even make it 0 or
below if you placed it at the top edge) and not where it visually has jumped to.

That is, at this point JavaScript's interface to DOM says the image is near the
top of the window, and your eyes tell you it's near the bottom.  And it depends
on other uninvolved images in the file.
(Reporter)

Comment 1

17 years ago
And to point you at the parts of my scripts I suspect are exercising the bug:

Essentially what is happening is that a setInterval from trajectory.js is doing
     object.image.width = new_width;
     object.image.height = new_style;
at the same time as a setTimeout from drag.js is doing
     object.image.style.left = new_left;
     object.image.style.top  = new_top;

So the first thing I suggest looking at is the Mozilla code that implements
those two actions.  Is there any chance that they could step on each other?
I see this on Linux too.... computed style agrees with the visual display, and
both disagree with the inline style.

Haven't looked at the code yet... does it all use inline style? Or does it use
any stylesheets and twiddle classes dynamically to make objects match various
selectors?
OS: Mac System 9.x → All
Hardware: Macintosh → All
(Reporter)

Comment 3

17 years ago
It uses inline style.

I propose someone at least look into whether it's an easy fix by Mozilla 1.0.
Keywords: mozilla1.0
So... I just revisited this intending to figure out what's going on, and I can
no longer reproduce it (in a current trunk build).  Bob, are you still seeing this?
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
Bob, is this still a problem?

Updated

15 years ago
Blocks: 236849

Comment 7

10 years ago
bz, closing based on your comment 4, as Bob's email address is dead and no response to comment 6.  please adjust if I'm off base.
Assignee: general → nobody
Status: NEW → RESOLVED
Last Resolved: 10 years ago
QA Contact: ian → general
Resolution: --- → INCOMPLETE
Sounds about right.
You need to log in before you can comment on or make changes to this bug.