details tag: grouped details browser search bug
Categories
(Core :: Find Backend, defect)
Tracking
()
People
(Reporter: constantin.schellhammer, Unassigned)
References
(Blocks 1 open bug)
Details
Steps to reproduce:
If multiple details tags are grouped via name attribute, then searching with Ctrl+F seems to not be able to keep the corresponding details tag open in case the search word appears in multiple details tags.
Steps to reproduce:
Search via Ctrl+F in 2 or more details tags containing the search word.
Actual results:
Closed details tags get opened temporarily.
Expected results:
Only the details tag with the active search word should open/stay open.
testcase:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Bug</title>
</head>
<body>
<details name="group">
<summary>Summary 1</summary>
<div>Content 1</div>
</details>
<details name="group" open>
<summary>Summary 2</summary>
<div>Content 2</div>
</details>
</body>
</html>
|
||
Updated•10 months ago
|
|
||
Comment 1•10 months ago
|
||
This sounds very familiar, does it ring a bell jan?
|
||
Comment 2•10 months ago
|
||
This should be Bug 1970909. The fix shouldn't be too hard. Currently, every call to nsFind::Find does the auto-expanding dance. So, if find-in-page goes through the doc to find all occurrences, it expands every details element. A similar thing might happen when opening a page with a text fragment which has other matches inside of an "accordion" details group. I'll use Bug 1970909 to track this.
Description
•