112836 - Failing to position elements exactly

Status: RESOLVED DUPLICATE of bug 92868

(Core :: DOM: CSS Object Model, defect, P2)

Description

[pbotsas]

I'm trying to position element with
document.getElementbyId("<objectID>").left and
document.getElementbyId("<objectID>").top

But the values are ignored.

More cunfusing is that I can ask for the current top/left position of an element
after changing it's position. The values are correct but the element is rendered
wrong. Neither top nor left attributes are accepted.

If the positioning parameters are entered directly within the style attribute
inside a <DIV>-tag, the element will render to the specified position. I need to
calculate the position of this element dynamically due to changes within a form.

Is this a bug, so I need to force only IE-development, or is there a simple
workaround, or am I missing something?

Comment 1

[Ashley Bischoff (blog at handcoding.com)]

Please always include a Build ID!

You may wish try a more recent build:
http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32-talkback.zip
(as always, be sure to delete your old Mozilla directory before installing the
new one)

Also, in future, please use the Bugzilla Helper for filing bugs:
http://www.mozilla.org/quality/help/bugzilla-helper.html
(among other things, it automagically adds your build id)

-> normal

Comment 2

[pbotsas]

Build: Netscape 6.2 Browser!!!

This line is in "about:"
Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4) Gecko/20011019 
Netscape6/6.2

Noticed that it is a alreay shipped product?

I don't think, that this is a normal bug :/

I also found some former bug reports. I guess they were ignored!!! Because they 
are reported in September 2000 (in words: two-thousand!!!)

I think we will keep Microsoft as a standard.

Thanks for your efford!

Comment 3

[Fabian Guisset]

CC'ing bz. He probably knows the answer.
I think the correct way to do this is to do:
document.getElementById(objectId).style.left = "10px";
document.getElementById(objectId).style.top = "10px";

Comment 4

[pbotsas]

I tried it this way too... but no results!

As I said. The only way to say where exactly the element is placed is withing 
its own <DIV>-tag. But on opening the document, I don't know where to place the 
element!

And I don't want to generate the whole page in JavaScript-writeln-orgies.

Searching for solutions...

Comment 5

[Boris Zbarsky [:bzbarsky]]

OK.  What fabian said _should_ work.  Is the element whose .style.left and
.style.right you are changing is absolutely positioned? Can you possibly attach
the HTML in which it does not to this bug using
http://bugzilla.mozilla.org/attachment.cgi?bugid=112836&action=enter ?  Or even
just put the URL of the page in question in the URL field (if it's publicly
available)?

Thanks,
Boris

Comment 6

[Karl Johan Kleist]

Reporter: Why do you call this a "blocker"? That's an extraordinary
severity level mainly for Mozilla developers and QA people.

Mozilla people: Maybe the explanation of "blocker" is a bit vague?

    Blocker: Blocks development and/or testing work

Maybe if the word "Mozilla" was substituted for the trailing "work",
the meaning would become more clear? Now a lot of Mozilla _users_
believe that _their_ work is referred to.

Or have I misunderstood the whole issue?

Comment 7

[R.K.Aa.]

This is not a blocker.

Comment 8

[pbotsas]

Finally solved...

But whooohow, don't tell me that this is normal :)

Well after <DIV>-ing all elements, which needed to be positioned and creating
for every table cell a separate table which wasn't part of the layout table AND
telling every <DIV> that is has to be positioned absolute starting with
left:0px; right:0px it worked for me. When I stripped of those "zero-handlers"
it is not working :(

I never thought that this would ever run! But now I'm tired because I worked the
whole weekend on that f***nny thing. And seeing the result I'm really fed up!
Tell me that I'm bad, but for me this issue was a blocker, because it blocked my
whole weekend! Sorry! But now I have to take some sleep anyway.

Comment 9

[Ashley Bischoff (blog at handcoding.com)]

So... WFM?

Comment 10

[pbotsas]

As mentioned before. It works for me, if I do an extraordinary workaround.

So this is a bug, which has to be fixed in future. For now this thing works, 
but not as expected within a table tag... and not as expected without zero-ing 
the absolute position first...

Please keep this bug in mind.

Tank you.

Comment 11

[Jason Johnston]

Reporter, we still need a testcase that reproduces this bug!  Otherwise, our
developers have nothing to go on.

Please attach an HTML file that demonstrates this bug using
http://bugzilla.mozilla.org/attachment.cgi?bugid=112836&action=enter

Comment 12

[Fabian Guisset]

We don't mark bugs as remind. If it's a bug (i.e. the behaviour is not as
expected/intended), even if there is a workaround, then it should be NEW or
ASSIGNED. Thanks :-)

Comment 13

[pbotsas]

I have to change some information on that form an will send it to you as soon 
as possible. 

Comment 14

[Boris Zbarsky [:bzbarsky]]

This is all well and good, but at the moment we have to mind-read to figure out
what the bug actually is!  There is still no testcase, no clear description of
the problem, nothing.

As near as I can tell from the comments, the problem arose because
non-positioned table cells are not containing blocks for absolutely positioned
elements.  If so, then this is correct behavior.

Reporter, please add some information to this bug that actually describes the
problem instead of just saying "there is a problem but I refuse to tell you what
it is".  Otherwise there's really nothing we can do to fix this bug....

Comment 15

[Fabian Guisset]

bz, 6 minutes between his comment and yours, shame! *laugh*
please do post the testcase :-)

Comment 16

[pbotsas]

I will attach a testcase where the following was expected to be...

Within the table "INFO8" there is a class and id definition.
There is one onClick-Event within the table. This event should get the 
offsetTop and offsetLeft properties of the INFO8Off-Element and hide it (that 
works best!). Now it should set the properties left/top of the INFO8On-Element 
and show it. Changing the visibility is perfect, but the element INFO8On is 
rendered on position 0,0 (absolute). If I read the properties left/top of this 
element it tells me, that it's position is somewhere else, but not at 0,0 
(absolute).

My workaroud here was:
Embedding the table (for element INFO8On and INFO8Off) in separate DIVisions. 
But it still didn't work for me. So I explicitly positioned the element on 0,0 
absolute on loading the page. After that it worked like a charme.

Now to the bad part... If this INFO8-element is part of a table, Netscape 
refuses to position the element EVEN IF it is embedded in a DIV and the 
attributes for absolute position are defaulted to 0,0.

Comment 17

[pbotsas]

Attachment: testcase1.html has the testcase :)

Comment 18

[Boris Zbarsky [:bzbarsky]]

Attachment: Minimal testcase based on that testcase

Comment 19

[Boris Zbarsky [:bzbarsky]]

So... The problem is that changing the positioning of a table dynamically fails.
seeing this on Linux too...

Over to Pierre -- this looks like a possible consequence of bug 103533.

Comment 20

[Kevin McCluskey (gone)]

Bulk moving Moz1.2 bugs to future-P2. I will pull from this list when scheduling
work post Mozilla1.0

Comment 21

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

*** This bug has been marked as a duplicate of 92868 ***