Closed
Bug 588716
Opened 14 years ago
Closed 10 years ago
Find doesn't (CSS generated content)
Categories
(Toolkit :: Find Toolbar, defect)
Tracking
()
People
(Reporter: dav4is, Unassigned)
References
()
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 (.NET CLR 3.5.30729)
The example page is an outline, with numbered lines, like A1. B1. B2. &c
The letter prefixes for the numbers is generated with CSS, e.g.
.N2 a.UR:before {content:"B"; font-size:smaller;}
These letter prefixes are not found by the FireFox Find. E.g. "3." is found, but "B3." is not.
Reproducible: Always
Steps to Reproduce:
1. display the sample page
2. CTL-F
3. enter "d3" (w/o quotes) in the find window
4. Hit Next
Actual Results:
Unable to find it.
Expected Results:
Should find it.
I'm not sure. Nobody in the 11 years of commentary on that bug has mentioned FIND, Which is probably why my searching didn't find it. The bug 12460 folks all seem to be worried about SELECT and COPY. To me, the FIND aspect is more important. Is that so closely related to SELECT and COPY? If you think so, then mark this as a duplicate and I will take up that aspect of the campaign in the comments there.
I should point out that all major browsers also fail this test, Firefox, Safari, MSIE, Chrome -- but not Opera. Opera seems to work the way it should. I.e. it can find the generated text as well as the explicit.
Comment 4•14 years ago
|
||
bug 299830 reckons that it is a duplicate of bug 12460.
[Still not marking as a second opinion would be good]
Component: General → Find Toolbar
Product: Core → Toolkit
QA Contact: general → fast.find
Updated•10 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•