Closed Bug 282755 Opened 20 years ago Closed 19 years ago

Script hides select element's selection when in table

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: mozilla, Unassigned)

Details

(Keywords: helpwanted, testcase)

Attachments

(1 file)

testcase
985 bytes, text/html
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217

In "Steps to Reproduce" I copy a self-explanatory HTML example.
A problem:
JavaScript sets up a "size", then a "selectedIndex" property value of a "select"
element.
If a "select" element is placed in table, a position of the select's scroll is
bad: selected item gets hidden.
An identical "select" element works well when it is not in a table.

Reproducible: Always

Steps to Reproduce:
<!-- load the following HTML file, hit Alt+S (or click a "Screw up" button): -->
<html>
<head>
	<title>Script hides selection</title>
	<script language="javascript">
	function ScrewUp() {
		sel = document.getElementById("sel_bad");
		sel.size=3;
		sel.selectedIndex=5;
		sel = document.getElementById("sel_good");
		sel.size=3;
		sel.selectedIndex=5;
	} // ScrewUp
	</script>
</head>
<body>

<button onclick="ScrewUp()" accesskey="S"><u>S</u>crew up!</button>
<br/><br/>
<table><tr>
<td><nobr><u>B</u>ad behavior &mdash; does not scroll to
selection:&nbsp;</nobr></td>
<td>
<select id="sel_bad" accesskey="B">
	<option>1</option><option>2</option><option>3</option><option>4</option><option>5</option><option>6</option><option>7</option><option>8</option><option>9</option>
</select>
</td>
</tr></table>
<p><u>G</u>ood behavior:<br/>
<select id="sel_good" accesskey="G">
	<option>1</option><option>2</option><option>3</option><option>4</option><option>5</option><option>6</option><option>7</option><option>8</option><option>9</option>
</select>
</p>

</body>
</html>
Actual Results:  
After running the JavaScript through hitting the button:
1) The "select" element labeled "Bad" (id="sel_bad") chandes size and hides
selection. It can be seen only after scrolling down manually.
2) The "select" element labeled "Good" (id="sel_good") does the same, but
scrolls down until new selection is visible.

Expected Results:  
1) Both "select" elements must work in the same way. The only difference is that
the one labeled "Bad" is placed in a table.
2) Whatever a script does to the element's property values, selected items must
be kept visible.
Attached file testcase — 
Assignee: general → nobody
Component: General → Layout
Keywords: helpwanted
Product: Mozilla Application Suite → Core
QA Contact: general → layout
Version: unspecified → Trunk

    
    

    
  
Attachment 175471 [details] WFM, Gecko/20050912 Firefox/1.6a1. Reporter, could you please 
verify whether you still the problem in Firefox 1.5b1?
Keywords: testcase

    
    

    
  
(In reply to comment #2)
> Attachment 175471 [details] [edit] WFM, Gecko/20050912 Firefox/1.6a1. Reporter, could
you please 
> verify whether you still the problem in Firefox 1.5b1?

No, I have just tested it with Firefox 1.5b1 and cannot see the problem anymore.

It was subtle and with variations (like different size via select's parameter
size="2") it was less serious (unconsistent behavior with control inside or
outside table: select scrolled to different positions, still selected items are
visible). With Firefox 1.5b1, such unconsistecies also gone; so now it looks
just fine.

However, I still see the problem with Mozilla 1.7.11.

    
    

    
  
WFM, SeaMonkey 2005-09-08-03 trunk Linux

-> WORKSFORME
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME

    
    

    
  
Fixed in Firefox 1.5 beta 1, but still appears in freshly published Mozilla 1.7.12
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---

    
    

    
  
New versions of Firefox 1.0.x / Mozilla 1.7.x receive only critical security or 
crash fixes, so this bug will never get fixed there. The latest builds of 
Firefox 1.5 / SeaMonkey 1.0 is what counts here.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → WORKSFORME

    
    

    
  
Tested with Firefox 1.5 (both XP Pro and Win2K Pro). The bug is fixed.
Tested with Seamonkey 1.0 (both XP Pro and Win2K Pro). The bug is fixed.
Thank you!

It looks like the only problem is Mozilla v<=1.7.12
(abandoned, anyway, as I understand)
OS: Windows 2000 → Windows XP

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: