Closed
Bug 51037
Opened 24 years ago
Closed 23 years ago
moving an absolute/fixed table gets "backed up"
Categories
(Core :: DOM: Core & HTML, defect, P3)
Core
DOM: Core & HTML
Tracking
()
VERIFIED
FIXED
mozilla1.0
People
(Reporter: p.malka, Assigned: karnaze)
References
Details
(Keywords: dom0, testcase, Whiteboard: [awd:tbl][eapp])
Attachments
(1 file)
(deleted),
text/html
|
Details |
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élection</th></tr></thead>
<tr>
<td>Sélection</td>
</tr>
<tr>
<td>Suppression</td>
</tr>
<tr>
<td>Création</td>
</tr>
<tr>
<td>Ajout</td>
</tr>
<tr>
<td>Modification</td>
</tr>
</table>
</BODY>
</HTML>
------------------------------------------------
Comment 1•24 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•24 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•24 years ago
|
||
Comment 4•24 years ago
|
||
Comment 5•24 years ago
|
||
I'm using build 2000091808 on Windows 98.
Comment 6•24 years ago
|
||
Looks like a table reflow problem, Chris, could you have a look?
Assignee: jst → karnaze
OS: Windows 2000 → All
Hardware: PC → All
Comment 7•23 years ago
|
||
Can anyone give this one a quick gander?
It doesn't look like a testcase problem.
Assignee | ||
Comment 8•23 years ago
|
||
Temporarily moving to future until a milestone can be assigned.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Updated•23 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+
Updated•23 years ago
|
Target Milestone: Future → ---
Comment 10•23 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.
Comment 11•23 years ago
|
||
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•23 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•23 years ago
|
Assignee | ||
Comment 13•23 years ago
|
||
Fixed with bug 92868
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 14•23 years ago
|
||
Re-opening, as the checkin which fixed this bug has been backed out due to
severe regressions (bug 129827).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 15•23 years ago
|
||
WORKSFORME, build 2002-03-09-08 (trunk) on Windows 98 SE.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME
Comment 16•23 years ago
|
||
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•23 years ago
|
Status: REOPENED → ASSIGNED
Assignee | ||
Comment 17•23 years ago
|
||
Fixed by the patch in bug 92868.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•