Closed
Bug 273525
Opened 20 years ago
Closed 14 years ago
Inconsistent (and partly incorrect) selection depending on format of source
Categories
(SeaMonkey :: Find In Page, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: guusdk, Unassigned)
Details
(Keywords: helpwanted)
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041206
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041206
Find as you Type returns different and possibly incorrect links, depending on
the way you format your source. See the two example html-fragments.
Assume we're looking for the link 'target3', identified by the string "online".
After typing the first two characters of the string ('o' and 'n') the selected
target of the two pages differs.
Reproducible: Always
Steps to Reproduce:
1. Load both files in seperate browser-tabs or windows.
2. Using type-ahead, try to access the third link (target3, "online") by typing
the first two letter ('o' and 'n')
Actual Results:
In the file which has all anchor-elements on the same line (no linebreaks in the
source), the last letter of the first link and the first letter of the second
link are selected. The anchor 'target1' is selected.
Expected Results:
the first two letters of the third link (anchor 'target3') should have been
selected, just like how it is selected in the file where the three
anchor-elements are on seperate lines in the source.
<html><body>
<!-- no problem in this file -->
<a href="target1">clandistino</a><br>
<a href="target2">nothing hill</a><br>
<a href="target3">online</a>
</body></html>
<html><body>
<!-- problematic -->
<a href="target1">clandistino</a><br><a href="target2">nothing hill</a><br><a
href="target3">online</a>
</body></html>
Comment 1•20 years ago
|
||
Comment 2•20 years ago
|
||
Comment 3•20 years ago
|
||
one line testcase: typing o highlights last letter in 1st link typing n highlights first letter in 2nd link, so 'on' is marked across linebreak typing l highlights first three letters in third link, problem resolved. three line testcase: typing o highlights last letter in 1st link typing n highlights first two letters in third link, link found. So behaviour indeed is different, depending on the source format two or three chars are needed to select the third link. Reducing the severity to minor, as typing the third char resolves the problem
Severity: normal → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•20 years ago
|
Keywords: helpwanted
| Assignee | ||
Updated•16 years ago
|
Product: Core → SeaMonkey
Comment 4•15 years ago
|
||
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
Comment 6•14 years ago
|
||
WFM with Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101206 Firefox/4.0b8pre SeaMonkey/2.1b2pre We switched the the find implementation in bug 97023.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•