1116904 - Findbar / find in page breaks if "hidden" (offscreen-positioned) position:absolute or other content is in the DOM in the middle of the searched-for content

Status: NEW

(Toolkit :: Find Toolbar, defect, P5)

Description

[Önder Örnek]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:34.0) Gecko/20100101 Firefox/34.0
Build ID: 20141126041045

Steps to reproduce:

As I tried to find a long number on a page the incremental Find function was not able to match the number after 6th digit. 



Actual results:

You can try it on the following page with the number 858351503002:
http://www.ersatzteile-blitzschnell.de/geraetesuche.html?login=187676N&V360020=BAUKNECHT

The first 6 digits 858351 were highlighted correctly. After I entered the digit 5 Firefox showed on the Find Toolbar the error text: "Phrase not found".


Expected results:

I expected that Find function should highlight/match all the digits I entered correctly.

Comment 1

[Loic]

Same result with IE11. Where is the number 858351503002 on the page?

Comment 2

[Alice0775 White]

I think this is correct behavior. there is position:absolute elements between those digits.

For example:

.yxditn {
    position: absolute;
    left: -1000px;
    top: -1000px;
}
.bjtxkynrxfh {
    position: absolute;
    left: -1000px;
    top: -1000px;
}
<span class="zjjsengek">8</span>55275<span class="yxditn">LIMFNKEKSMJFLTUKJJOPSKDLK</span>60<span class="bjtxkynrxfh">RPEFJGPFPHNHKVMSOOVOFETLCJCD</span>1030				</a>	

855275 found, but 8552756  not found. 'LIMFNKEKSMJFLTUKJJOPSKDLK' exist between 5 and 6.

Comment 3

[Önder Örnek]

(In reply to Alice0775 White from comment #2)
> I think this is correct behavior. there is position:absolute elements
> between those digits.
> 
> For example:
> 
> .yxditn {
>     position: absolute;
>     left: -1000px;
>     top: -1000px;
> }
> .bjtxkynrxfh {
>     position: absolute;
>     left: -1000px;
>     top: -1000px;
> }
> <span class="zjjsengek">8</span>55275<span
> class="yxditn">LIMFNKEKSMJFLTUKJJOPSKDLK</span>60<span
> class="bjtxkynrxfh">RPEFJGPFPHNHKVMSOOVOFETLCJCD</span>1030				</a>	
> 
> 855275 found, but 8552756  not found. 'LIMFNKEKSMJFLTUKJJOPSKDLK' exist
> between 5 and 6.

That's the point! For a "normal" user the behaviour is not understandable because he is only interested in the content. You can not expect that every user should check the source code to decide if Find works correctly or not.

Maybe Firefox should show some additional information in the Find toolbar that the functionality is restricted by the web site or more technically the Find functionality should only work on the rendered HTML page without evaluating the CSS directives. I think both solutions need some architectural changes of Firefox.

Comment 4

[Önder Örnek]

(In reply to Önder Örnek from comment #3)
> (In reply to Alice0775 White from comment #2)
> > I think this is correct behavior. there is position:absolute elements
> > between those digits.
> > 
> > For example:
> > 
> > .yxditn {
> >     position: absolute;
> >     left: -1000px;
> >     top: -1000px;
> > }
> > .bjtxkynrxfh {
> >     position: absolute;
> >     left: -1000px;
> >     top: -1000px;
> > }
> > <span class="zjjsengek">8</span>55275<span
> > class="yxditn">LIMFNKEKSMJFLTUKJJOPSKDLK</span>60<span
> > class="bjtxkynrxfh">RPEFJGPFPHNHKVMSOOVOFETLCJCD</span>1030				</a>	
> > 
> > 855275 found, but 8552756  not found. 'LIMFNKEKSMJFLTUKJJOPSKDLK' exist
> > between 5 and 6.
> 
> That's the point! For a "normal" user the behaviour is not understandable
> because he is only interested in the content. You can not expect that every
> user should check the source code to decide if Find works correctly or not.
> 
> Maybe Firefox should show some additional information in the Find toolbar
> that the functionality is restricted by the web site or more technically the
> Find functionality should only work on the rendered HTML page without
> evaluating the CSS directives. I think both solutions need some
> architectural changes of Firefox.

Additionally you are talking about 855275 not about my example number 858351503002. I'm not sure if your explanation relevant for the issue.

Comment 5

[Önder Örnek]

(In reply to Loic from comment #1)
> Same result with IE11. Where is the number 858351503002 on the page?

Sorry, there was another frame. The relevant content is on the following page:

http://www.ersatzteile-blitzschnell.de/relink.html?url=http%3A%2F%2Fshop.euras.com%2Fgeraetefinder.php%3Fredirect%3D1%26V360020=BAUKNECHT%26vonV360060=WAK6950%26bisV360060=WAK7508%26g7=187676N

Comment 6

[Önder Örnek]

Please click the link in the URL field of this bug for the relevant HTML page.

Comment 7

[:Gijs (he/him)]

(In reply to Önder Örnek from comment #4)
> (In reply to Önder Örnek from comment #3)
> Additionally you are talking about 855275 not about my example number
> 858351503002. I'm not sure if your explanation relevant for the issue.

It is.

> > That's the point! For a "normal" user the behaviour is not understandable
> > because he is only interested in the content. You can not expect that every
> > user should check the source code to decide if Find works correctly or not.

An admirable sentiment, of course. How do you suggest that Firefox determines that this is the case?

> > Maybe Firefox should show some additional information in the Find toolbar
> > that the functionality is restricted by the web site

But how would it detect that it is "restricted" ?

> > or more technically the
> > Find functionality should only work on the rendered HTML page without
> > evaluating the CSS directives.

In that case, your string would still not match; the content in the middle of the text you're trying to find would still be in the middle of it... you kind of want the opposite - you want Find to be clever and extract readable text instead, expressly taking the CSS into account. That is very difficult.

> > I think both solutions need some
> > architectural changes of Firefox.

They also need more specification...

Comment 8

[Mike de Boer [:mikedeboer]]

As per comment 7, this would take a considerable amount of work even _if_ we would be able to specify the behavior fully.
Considering the amount of resources we have available to work on low priority improvements like this, I'm thinking it's best to WONTFIX this issue.