Closed Bug 273681 Opened 20 years ago Closed 18 years ago

Listbox fails to retain the visibly selected position when the text value of the selected element is modified within a set of N elements where N > SIZE property >0 and the selectedIndex value > SIZE.

Categories

(Core :: Layout: Form Controls, defect)

Product:
Core
Component:
Layout: Form Controls
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: arsukdeo, Unassigned)

References

Details

(Keywords: testcase, Whiteboard: QA: Ignore comments 1 -- 5)

Attachments

(3 files, 1 obsolete file)

Slightly reduced testcase
1.43 KB, text/html
Details
minimal testcase
653 bytes, text/html
Details
The tests
2.38 KB, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20041207

Having a list box with the property SIZE>0, and having N elements greater than 
the SIZE value, and the users scrolls down the list to select an element at the 
(SIZE+1) position, then if a bit of code executes on the form to modify the 
text value of the selected element, the list box scrolls back to the top SIZE 
viewable elements.

Reproducible: Always
Steps to Reproduce:
<HTML>
<TITLE>Mozilla Browser Test Case from TECHNOCORP</TITLE>
<SCRIPT type="text/javascript">
function setPos()
   {
   var obj = document.frmObj;
   var pos = obj.m_select.selectedIndex;
   obj.m_text.value = pos;
   if (obj.m_select.length > 0)
      {
      if (obj.m_select.selectedIndex > 0)
         {
         obj.m_select.selectedIndex = 0;   
         obj.m_select.selectedIndex = pos;
         }
      else
         obj.m_select.selectedIndex = 0;
      }
   }

function doScroll()
   {
   var obj = document.frmObj;
   var pos = obj.m_select.selectedIndex;
   if (obj.m_select && obj.m_select.length > 0)
      {
      obj.m_select.selectedIndex = 0;
      obj.m_select.selectedIndex = pos;
      alert("Position rescrolled before element modification.");
      obj.m_select.options[pos].text = obj.m_select.options[pos].text + " - 
tag";
      alert("Element modified.");
      alert("Current selection position: "+ obj.m_select.selectedIndex+".");
      obj.m_text.value = obj.m_select.selectedIndex;
      }
   }


</SCRIPT>
<BODY>
<FORM NAME=frmObj>
<TABLE BORDER=1 style=width:400px">
<TR><TD COLSPAN=2>
1.  Scroll down to any element after the 2nd element.<BR>
2.  Select the element.<BR>
3.  Click the Re-Scroll button to see bug.<BR>
    Note that the selected item was modifed, and did retain the "selectedIndex" 
property value. &nbsp;
    But the modification appears to trigger an event that scrolls the listbox 
to the first element.
</TD>
</TR>
<TR><TD>
<SELECT SIZE=2 NAME=m_select onClick="setPos()">
<OPTION>A</OPTION>
<OPTION>B</OPTION>
<OPTION>C</OPTION>
<OPTION>D</OPTION>
<OPTION>E</OPTION>
<OPTION>F</OPTION>
<OPTION>G</OPTION>
<OPTION>H</OPTION>
<OPTION>I</OPTION>
<OPTION>J</OPTION>
<OPTION>K</OPTION>
<OPTION>L</OPTION>
<OPTION>M</OPTION>
<OPTION>N</OPTION>
</SELECT>

</TD>
<TD><INPUT TYPE=BUTTON VALUE="Re-Scroll" onClick="doScroll()"></TD>
</TR>
<TR><TD COLSPAN=3>Report Position:<INPUT TYPE=TEXT NAME=m_text 
VALUE=""></TD></TR>
</TABLE>



</FORM>
</BODY>
</HTML>

Actual Results:  
The listbox fails to maintain the visibility of the selected element at 
the "selectedIndex" position after the text value of the selected element is 
modified.

Expected Results:  
If a bit of code scrolls the listbox, by using the "selectedIndex" property, 
subsequent changes to the TEXT value of the selected element should not cause 
the listbox to (scroll up and) display the first SIZE number of elements.

This bug exists in the latest Firefox build.  

It is not a major bug in the behaviour of the listbox, because the workaround 
for a simple implementation involves modifying the "text" value first before 
calling any code to scroll the listbox on the "selectedIndex" property.  
However, for more complex implementations with listboxes, where it is not 
possible to do this, one has to call a timed event/subroutine/handle to do the 
scrolling, which results in a slight quirky/slow behaviour of the browser to 
the ordinary user.  I hope this bug can be fixed in the next major release of  
Mozilla/Firefox.
*** Bug 274017 has been marked as a duplicate of this bug. ***
hi

i cannot get the following code working. Firefox isn't scrolling down in the
listbox! the reporters comment about a workaround isn't working! 

var moveText1 = document.getElementById(listField)[selected+1].text;
var moveValue1 = document.getElementById(listField)[selected+1].value;
var moveText2 = document.getElementById(listField)[selected].text;
var moveValue2 = document.getElementById(listField)[selected].value;
document.getElementById(listField)[selected].text = moveText1;
document.getElementById(listField)[selected].value = moveValue1;
document.getElementById(listField)[selected+1].text = moveText2;
document.getElementById(listField)[selected+1].value = moveValue2;
document.getElementById(listField).selectedIndex = selected+1; // Select the one
that was selected before


please fix this in next release!
I agree that this bug has to be fixed for both browsers in their next releases: 
Mozilla and Firefox.  The workaround is not obvious.  It requires an 
understanding of the behaviour of listboxes.  So, it makes sense to fix this 
bug.

Direct reference to the SELECT object via the form object, and any CSS 
reference to the SELECT object via getElementById, should be successful in 
manipulating a "listbox".

As a follow up on the workaround, for those who need an immediate solution to 
their problems, consider modifying the submitted test case as follows, to have 
an understanding of the workaround:

1.  First assign an ID to the SELECT elment.  I will use "listField" from the 
lastest feedback:  SELECT SIZE=2 ID="listField" NAME=m_select onClick="setPos()"

2.  Insert a call to doScrollCSS in the doScroll() function of the test case, 
and add the implementation of doScrollCSS below to the rest of the test case 
code:

function doScroll()
   {
   doScrollCSS();
   return;
   ...
   }

function doScrollCSS()
   {
   var elm = document.getElementById("listField")
   if (elm)
      {
      var pos = elm.selectedIndex;
      elm.selectedIndex = 0;
      elm.selectedIndex = pos;
      alert("Position rescrolled before element modification.");
      elm[pos].text = elm[pos].text + " - tag";
      alert("Element modified.");
      alert("Current selection position: " + elm.selectedIndex + ".");
      elm.selectedIndex = 0;
      elm.selectedIndex = pos;
      }
   }

Notice that the last two assignment lines forces a change in the value of the 
selectedIndex property to trigger a scroll.

I hope this helps.
> The workaround is not obvious.  It requires an 
> understanding of the behaviour of listboxes.  So, it makes sense to fix this 
> bug.

i understand you code example, but i cannot see the workaround! if i remove the
alerts from your tip - it don't work! with the alert boxes it works! but i
cannot do the alerts to the user and therefor this workaround isn't useable.

DO NOT WORK: 
> function doScrollCSS()
>    {
>    var elm = document.getElementById("listField")
>    if (elm)
>       {
>       var pos = elm.selectedIndex;
>       elm.selectedIndex = 0;
>       elm.selectedIndex = pos;
>       }
>    }

WORK: 
> function doScrollCSS()
>    {
>    var elm = document.getElementById("listField")
>    if (elm)
>       {
>       var pos = elm.selectedIndex;
>       alert("Element modified.");
>       elm.selectedIndex = 0;
>       elm.selectedIndex = pos;
>       }
>    }
function doScrollCSS()
   {
   var elm = document.getElementById("listField")
   if (elm)
      {
      // Here is the actual conceptual elaborate work-around mechanism 
      // that was used in the EXTENDANT(tm) platform from TECHNOCORP(tm),
      // after an elment in a listbox is modified.  The delay timed call to 
      // actually scroll the listbox is determined by specific implementation
      // requirements, for the optimal millisecond value.  This is the reason
      // why I reported the bug for fixing, and the context for the initial
      // report for both the Mozilla and Firefox browsers.
      var pos = elm.selectedIndex;
      elm[pos].text = elm[pos].text + " - tag";
      var nMOZILLA_DelayCall = 500;  //Can optionally be in global scope space.
      var nTimerID = setTimeout("doScrollDelay("+pos+")", nMOZILLA_DelayCall);
      }
   }


function doScrollDelay(pos)
   {
   if (pos < 1)
      return;
   var elm = document.getElementById("listField")
   if (elm)
      if (elm)
      {
      elm.selectedIndex = 0;
      elm.selectedIndex = pos;
      }
   }

P.S. As of this date, the usage of EXTENDANT as a trademark and service mark in 
the context as defined by www.technocorp.com (TECHNOCORP) is unique for all 
usages recorded by all search engines, globally.  TECHNOCORP is happy to help 
this community and it hopes the community can return the favour by helping it 
protect its investments (from current and future squatters).  The sample code, 
extracted from the EXTENDANT(tm) platform, is provided as is, without any 
warranties of any sort.  Please do not use this code (or any other code 
provided to this commuity) in any situation that can cause harm to others or 
their personal or commercial investments.  Thank you and good luck.
Attached file Testcase in a usable form. (obsolete) — 
Whiteboard: QA: Ignore comments 1 -- 5

    
    

    
  


  

        Attachment #171015 -
        Attachment is obsolete: true

    
    

    
  
So I did some testing, and it doesn't look like the select is scrolling itself
-- ScrollToIndex() is not being called when I click the button.

If I modify nsListControlFrame::DidReflow() to unconditionally scroll to the
selection, the bug disappears, of course...

So it looks like something else is scrolling the list control to the beginning.
 Mats, Robert, David, any idea what that could be?

    
    

    
  
Notice: (sorry Marc)

The workaround I had proposed does not work in the recently released Mozilla 
1.75 browser.  I guess some of the fixes in the few nightly builds under which 
it is possible to use the workaround did not make into this release.

Personally, this is a major issue for me because the EXTENDANT product my 
(small) company is about to release will not be able to properly support the 
browsers.
Version: unspecified → Trunk

    
    

    
  
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/


    
    

    
  
This bug has been confirmed by different users and is NOT fixed in Firefox 1.5 
Beta 1
Keywords: helpwanted

    
    

    
  
I would suggest that this bug be fixed once and for all.  Otherwise, the power 
of the browser is being limited.

    
    

    
  

      
      
      
      

        Attached file
          
        minimal testcase
        — 
      

    


  
Scroll down, select an option, click Re-Scroll button.

With linux trunk 2005100102, the list scrolls to the top and stays there
although the previously selected element stays selected (and was properly
changed).

    
    

    
  
==> form controls
Assignee: general → nobody
Status: UNCONFIRMED → NEW
Component: General → Layout: Form Controls
Ever confirmed: true
Keywords: testcase
OS: Windows 2000 → All
Product: Mozilla Application Suite → Core
QA Contact: general → layout.form-controls

    
    

    
  
Fixed by reflow branch landing.  Checked in tests to reftest.
Status: NEW → RESOLVED
Closed: 18 years ago
Depends on: reflow-refactor
Flags: in-testsuite+
Keywords: helpwanted
Resolution: --- → FIXED

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: