Closed
Bug 1096042
Opened 10 years ago
Closed 3 years ago
Element not found when checking for closest clickable elements
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: domivinc, Unassigned)
References
()
Details
Attachments
(1 file)
11.20 KB,
text/plain
|
Details |
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 2013</a></li> - empty region : <a href="#_Toc362454444">Lync 2013</a> - clickable : Lync 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 2013</a></li> - not clickable: <li id="bmkTOClinks"><a href="#_Toc362454443">Access 2013</a></li> - ... The text element frames (clickable) are not in the list of frames. It's the reason why it doesn't work.
Reporter | ||
Comment 1•10 years ago
|
||
URL of the page with the issue: http://office.microsoft.com/fr-fr/training/cours-de-formation-sur-office-2013-HA104096598.aspx
Comment 2•10 years ago
|
||
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.
Comment 3•3 years ago
|
||
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.
Description
•