Closed Bug 1096042 Opened 10 years ago Closed 3 years ago

Element not found when checking for closest clickable elements

Categories

(Core :: Layout, defect)

defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: domivinc, Unassigned)

References

()

Details

Attachments

(1 file)

Spinoff from bug 1078029 (comment 56) on that bug and from bug 1093686 (partial fix).


Bug 1093686 fixed the body listener issue but it looks like there is another problem due to the html structure of the links.

Steps to reproduce the issue:
1- zoom out the page in order to get very small links
2- click on the left of 2 links (for instance "Access 2013" and "Lync 2013"), the closest link is correctly detected.
3- click on the right of the 2 same links, the closest link is never detected.

I tested the same points using Firefox 33 and it works in both cases. Closest link is correctly detected on the right or on the left side.

Kats I found the following list of frames in method "GetClosest". 
When it works (step 2), the list of frames contains the following elements:
- not clickable: <li id="bmkTOClinks"><a href="#_Toc362454444">Lync&nbsp;2013</a></li>
- empty region : <a href="#_Toc362454444">Lync&nbsp;2013</a>
- clickable : Lync&nbsp;2013
- ... same with "Access 2013"

When it doesn't work (step 3), the list of frames is:
- not clickable: <li id="bmkTOClinks"><a href="#_Toc362454444">Lync&nbsp;2013</a></li>
- not clickable: <li id="bmkTOClinks"><a href="#_Toc362454443">Access&nbsp;2013</a></li>
- ...

The text element frames (clickable) are not in the list of frames. It's the reason why it doesn't work.
See Also: → 1078029
See Also: → 1093686
I was able to reproduce this but as far as I can tell it's the GetFramesForArea call which is not including the link text when you click to the right of the link but it does include it when you click to the left of the link. I'm not sure how GetFramesForArea works, but this might actually be correct/expected behaviour. I'm attaching a log file that shows what's happening.

In the log file, the tap happens at (x=9240, y=16560) which is positioned over the frame 0x89ff8150. The point is expanded to the rect (x=8106, y=14670, w=2268, h=2646) using the ui.touch.radius prefs, and then GetFramesForArea is called on that rect. The various frames returned by that call are listed as the candidates in the log file. Note in particular the frame 0x89ff81f8 is never listed as a candidate, and that's the one we want it to hit. The code completes with a final target frame of 0x89ff8150 which is the <li> element and is not clickable, so nothing happens.

Below that is a snippet of the frame tree dump. I truncated the dump and removed all the previous-sibling frames that weren't on ancestor chain down to the "Access 2013" text since I figured they were irrelevant. I'm not sure what rects from the frames GetFramesForArea uses but it might be entirely correct for it to not find the "Access 2013" text.

Old bug that I think is no longer relevant.

Mentor: kats
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: