On Tue, Sep 17, 2013 at 12:30 PM, Gijs Kruitbosch
wrote:
> On 17/09/13 11:18 , Neil wrote:
>>
>> Gavin Sharp wrote:
>>
>> Probably the conceptually simplest solution is to get the bounding
>> client rect of the found range.
>
> Won't that be non-zero for visibility:hidden content?
Should be, as w
On 17/09/13 11:18 , Neil wrote:
Gavin Sharp wrote:
On Mon, Sep 16, 2013 at 5:12 AM, Aryeh Gregor wrote:
The real question is: what's the use-case you're trying to solve? If
it's some sort of optimization, false positives should be okay.
The find bar wants to avoid finding "hidden" text,
Gavin Sharp wrote:
On Mon, Sep 16, 2013 at 5:12 AM, Aryeh Gregor wrote:
The real question is: what's the use-case you're trying to solve? If it's some
sort of optimization, false positives should be okay.
The find bar wants to avoid finding "hidden" text, AIUI (see bug 257061). Some
On 2013-09-16 10:04 AM, Gavin Sharp wrote:
On Mon, Sep 16, 2013 at 6:04 AM, Aryeh Gregor wrote:
Probably the findbar code should continue implementing its own
checking, unless you're aware of other actual consumers that could
reuse the same code.
I agree, I don't think that we should be shoot
On Mon, Sep 16, 2013 at 6:04 AM, Aryeh Gregor wrote:
> Probably the findbar code should continue implementing its own
> checking, unless you're aware of other actual consumers that could
> reuse the same code.
I agree, I don't think that we should be shooting for some generic
solution. But we do
On Mon, Sep 16, 2013 at 3:24 PM, Gavin Sharp wrote:
> The find bar wants to avoid finding "hidden" text, AIUI (see bug
> 257061). Some false positives would certainly be OK. The findbar C++
> code already does something not-quite-perfect and we've lived with
> that for a while, so from my perspect
On Mon, Sep 16, 2013 at 5:12 AM, Aryeh Gregor wrote:
> The real question is: what's the use-case you're trying to solve? If
> it's some sort of optimization, false positives should be okay.
The find bar wants to avoid finding "hidden" text, AIUI (see bug
257061). Some false positives would certa
On Mon, Sep 16, 2013 at 1:07 PM, Mike de Boer wrote:
> * Is a node visible, with all CSS styling taken into account that might cause
> an element to not be visible, including parent nodes that might obscure it?
>
> In other words, when a node is painted on the canvas by the gfx layer,
> partiall
On Sep 13, 2013, at 10:00 PM, "Robert O'Callahan" wrote:
> On Fri, Sep 13, 2013 at 7:25 AM, Benjamin Smedberg
> wrote:
> This is a hard problem, and it depends on what question you're asking:
>
> * Is a node visible if it's in the window but some other window is covering
> the current window
On Fri, Sep 13, 2013 at 7:25 AM, Benjamin Smedberg wrote:
> This is a hard problem, and it depends on what question you're asking:
>
> * Is a node visible if it's in the window but some other window is
> covering the current window?
> * Is a node visible if it's currently scrolled out of view but
On a side note, fully tracking the visibility of images is bug 847221, but that
isn't going to tell you if the image is visible, just when it isn't.
--
- Milan
On 2013-09-13, at 10:25 , Benjamin Smedberg wrote:
> ...
>
> In general we don't track visibility of objects, and computing one more
On 9/13/2013 10:04 AM, Mike de Boer wrote:
…reliably from C++?
Some background: in bug 257061 I'm implementing to count and display the number
of found items in the findbar. Gavin mentions in
https://bugzilla.mozilla.org/show_bug.cgi?id=257061#c88 that there has to be
some prior art related t
12 matches
Mail list logo
