Dialog find should not find invisible text

VERIFIED FIXED in mozilla1.3beta

Status

defect
VERIFIED FIXED
17 years ago
11 years ago

People

(Reporter: aaronlev, Assigned: aaronlev)

Tracking

Trunk
mozilla1.3beta
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Assignee

Description

17 years ago
Either nsFind or nsWebBrowserFind should check the returned range to see if it
has visible frames.

Display:none styled content has no frames at all.
Visibility:hidden and visibility:collapsed frames can be found using the
following code:

  nsCOMPtr<nsIStyleContext> styleContext;
  frame->GetStyleContext(getter_AddRefs(styleContext));
  if (styleContext) {
    const nsStyleVisibility* vis = 
      (const nsStyleVisibility*)styleContext->GetStyleData(eStyleStruct_Visibility);
    if (!vis->IsVisible())
      printf("The frame is not visible!");
  }
Assignee

Updated

17 years ago
Summary: Dialog find should not invisible text → Dialog find should not find invisible text
we have a bug on this already, somewhere.

Comment 2

17 years ago
As part of the design, I explicitly didn't check with layout for visibility of
nodes while searching, for performance reasons (it's slow to ask layout that
information).  But that was assuming checking visibility of every node; if find
just waited until it found something, then checked visibility of the found range
before returning, that shouldn't hurt performance too much.

It's not necessarily completely accurate -- for instance, if we search for
mozilla and look through the string mozil<b>floopy</b>a where the <b> and its
children are invisible, we still won't find it.  But at least we won't find
totally invisible content, like we can now.

Kin, does this sound like it would be a good change?

(Simon's probably right that there's already a bug covering this somewhere ...
I'm not sure where, though; it's not on my list and I don't see it under the
(somewhat out of date) tracking bug 106961.
Blocks: 106961
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.3beta
Assignee

Comment 3

17 years ago
I have a fix for this in bug 175046, seeking r=akkana, sr=sfraser in that one.
Assignee: akkana → aaronl
Status: ASSIGNED → NEW
Assignee

Updated

17 years ago
Depends on: 175046
Assignee

Comment 4

17 years ago
this was fixed with checkin for bug 175046.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Component: Search → XP Apps: GUI Features
QA Contact: claudius → pmac
QA Contact: pmac → sairuh
rs vrfy.
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite

Updated

11 years ago
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.