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)
Tracking
()
RESOLVED
FIXED
People
(Reporter: arsukdeo, Unassigned)
References
Details
(Keywords: testcase, Whiteboard: QA: Ignore comments 1 -- 5)
Attachments
(3 files, 1 obsolete file)
|
(deleted),
text/html
|
Details | |
|
(deleted),
text/html
|
Details | |
|
(deleted),
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.
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.
|
||
Comment 1•20 years ago
|
||
*** Bug 274017 has been marked as a duplicate of this bug. ***
|
||
Comment 2•20 years ago
|
||
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.
|
|
||
Comment 4•20 years ago
|
||
> 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.
|
||
Comment 6•20 years ago
|
||
|
|
||
Updated•20 years ago
|
Whiteboard: QA: Ignore comments 1 -- 5
|
|
||
Comment 7•20 years ago
|
||
Attachment #171015 -
Attachment is obsolete: true
|
|
||
Comment 8•20 years ago
|
||
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.
|
||
Updated•20 years ago
|
Version: unspecified → Trunk
|
||
Comment 10•19 years ago
|
||
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/
|
|
||
Comment 11•19 years ago
|
||
This bug has been confirmed by different users and is NOT fixed in Firefox 1.5
Beta 1
|
|
||
Updated•19 years ago
|
Keywords: helpwanted
|
Reporter | |
Comment 12•19 years ago
|
||
I would suggest that this bug be fixed once and for all. Otherwise, the power
of the browser is being limited.
|
||
Comment 13•19 years ago
|
||
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).
|
|
||
Comment 14•19 years ago
|
||
==> 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
|
|
||
Comment 15•18 years ago
|
||
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
|
|
||
Comment 16•18 years ago
|
||
You need to log in
before you can comment on or make changes to this bug.
Description
•