moving an absolute/fixed table gets "backed up"

VERIFIED FIXED in mozilla1.0

Status

()

Core
DOM: Core & HTML
P3
normal
VERIFIED FIXED
18 years ago
16 years ago

People

(Reporter: Philippe Malka, Assigned: karnaze (gone))

Tracking

({dom0, testcase})

Trunk
mozilla1.0
dom0, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [awd:tbl][eapp])

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
M17 Build : 2000080712
Windows 2K
HTML snippet follows

Unable to dynamically position using JavaScript an HTML table.

	1 - Set both Left & Top fields to any numeric value, then click "Show" => the
table does not reposition

	2 - Reload the page click "Hide" then "Show" then "Hide" button the HTML table
repositions at (0,0) and the "Show" button seems disabled

------------------------------------------------
<HTML>
<HEAD>
<TITLE>Bug positionning table</TITLE>
<script>

var popup = null;
var field1 = null;
var field2 = null;

function onLoad()
{
	popup = document.getElementById("popup");
	field1 = document.getElementById("field1");
	field2 = document.getElementById("field2");
}

function showp()
{
	var t= field1.value;
	var l= field2.value;
	
	popup.style.visibility="visible";
	popup.style.left=l;
	popup.style.top=t;
}

function hidep()
{
	popup.style.visibility="hidden";
}

</script>

</HEAD>
<BODY onload="return onLoad();">

<form>
Left <input type=text name=fieldt id=field1 ><br><br>
Top  <input type=text name=fieldl id=field2 ><br><br>
<input type = button value=Show onclick="showp()" id=button1 name=button1><br><br>
<input  type = button value=Hide onclick="hidep()" id=button2 name=button2><br><br>
</form>

<table style="position:absolute;left:120px;top:120px" id=popup >
<thead><tr><th>Votre s&eacute;lection</th></tr></thead>
<tr>
	<td>S&eacute;lection</td>
</tr>
<tr>
	<td>Suppression</td>
</tr>
<tr>
	<td>Cr&eacute;ation</td>
</tr>
<tr>
	<td>Ajout</td>
</tr>
<tr>
	<td>Modification</td>
</tr>
</table>

</BODY>
</HTML>
------------------------------------------------

Comment 1

18 years ago
Browser, not engine. Reassigning to DOM Level 0 -
Assignee: rogerl → jst
Component: Javascript Engine → DOM Level 0
QA Contact: pschwartau → desale

Comment 2

18 years ago
This bug gets to be problem #1, that clicking "Show" the first time doesn't do 
anything.  If you change the numbers and then click "Show" again, the table 
moves to the first set of numbers you typed in.  Very strange.

I'll split the other problems off into other bugs.  Reporter, thanks for the 
fairly simple testcase and good instructions for reproducing the bug, but in 
the future please also try to keep each bug report limited to a single problem.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
Summary: Dynamically Positionning <table> HTML elements → moving an absolute/fixed table gets "backed up"

Comment 3

18 years ago
some other problems on the original page:
- bug 53663  position:absolute without top,left treated as 0,0
- bug 40828  cellpadding goes away

Comment 4

18 years ago
Created attachment 15279 [details]
testcase: new positions for table 'backed up'

Comment 5

18 years ago
I'm using build 2000091808 on Windows 98.
Looks like a table reflow problem, Chris, could you have a look?
Assignee: jst → karnaze
OS: Windows 2000 → All
Hardware: PC → All
Keywords: dom0

Updated

16 years ago
Whiteboard: [awd:tbl]

Comment 7

16 years ago
Can anyone give this one a quick gander?

It doesn't look like a testcase problem.
(Assignee)

Comment 8

16 years ago
Temporarily moving to future until a milestone can be assigned. 
Status: NEW → ASSIGNED
Target Milestone: --- → Future

Updated

16 years ago
Whiteboard: [awd:tbl] → [awd:tbl][eapp]
Major corporations depend on eapp bugs, and need them to be fixed before they
can recommend Mozilla-based products to their customers. Adding nsbeta1+ keyword
and making sure the bugs get re-evaluated if they are targeted beyond 1.0.
Keywords: nsbeta1+
Target Milestone: Future → ---

Comment 10

16 years ago
eapp was incorrectly used to change this to nsbeta1+. Resetting to nsbeta1 to
nominate. This is an important issue and deserves to be nsbeta1+ by the ADT.
Keywords: nsbeta1+ → nsbeta1
Bulk moving all nsbeta1 nominations to Moz1.1.  If the nomination is approved it
will be marked nsbeta1+ and moved to the Mozilla1.0 milestone.
Target Milestone: --- → mozilla1.1
(Assignee)

Comment 12

16 years ago
I'm planning to expand the patch in bug 92868 to fix this bug also, since the 
tree is closed, and I can't easily build upon that patch.
Depends on: 92868
Target Milestone: mozilla1.1 → mozilla1.0

Updated

16 years ago
Keywords: nsbeta1 → nsbeta1+
(Assignee)

Comment 13

16 years ago
Fixed with bug 92868
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Re-opening, as the checkin which fixed this bug has been backed out due to
severe regressions (bug 129827).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
WORKSFORME, build 2002-03-09-08 (trunk) on Windows 98 SE.
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → WORKSFORME
Mats, please re-read Comment #14.  This fix was _backed out_ (undone, removed)
_after_ the build you are using.

Re-opening.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(Assignee)

Updated

16 years ago
Status: REOPENED → ASSIGNED
(Assignee)

Comment 17

16 years ago
Fixed by the patch in bug 92868.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 18

16 years ago
Verified on 2002-05-23-08-trunk.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.