147955 - getting too many hits when performing a search on space " "

Status: RESOLVED EXPIRED

(SeaMonkey :: Composer, defect)

Description

[Jay Farrell]

In Composer, while entering data and removing lines for other tests, I came up 
with a file that contained just a few lines of text with spaces in it, like:

testing composer output
typing junk
gh ghgh

When I performed my search on space " " in Composer, I started cycling through
the existing space. The strange thing was, I'd click "Find next" and the cursor
would disappear, yet if I clicked again, it seemed to go to the next line.
I thought that this meant that it was treating CR or EOL as a space, but it 
didn't do it for all lines.
Did some more investigation and it seems that if I view the HTML source for the 
composer window, there are spaces there, yet those space do not show up in my 
normal view!  I think the cutting and pasting/adding removing of text is 
getting formated in the HTML source page, and when I do a search for space, it 
seems to be finding the spaces added to the HTML source, even though there are
no such spaces on the norm view page!
Even more investigation showed that the spaces are being added to the HTML code 
when I copy/paste multiple lines. If I only copy/paste one line, it doesn't add 
an extra space at the beginning of the line, but if I copy 2 or more lines, 
then the second (and third, forth, etc..) line gets a space added to the 
beginning.

So, is this a problem with cut and paste adding in extra spaces, or a search 
problem?  Since I found this while doing the search tests, I'll open it there.
Feel free to reassign it as you see fit.
(Saw this on rc2, openVMS build 20020513 and Linux 2002051009)

Comment 1

[Akkana Peck]

This would be me, but I don't know if it's possible to solve it, at least
without drastically slowing down all searches.  Those spaces really are in the
content model, and our content model doesn't make any distinction between spaces
used for html formatting and spaces which are visible on the screen.  It is
possible to ask layout about what's displayed on the screen, but that's a lot
slower than just going through the content model. 

Comment 2

[Robert Kaiser]

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

Comment 3

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420