This morning I realized how stupid that was : i'm creating my Tree from the HTML content only, while the object position can be influenced by the Javascript (And other stuff? And something that manages the display layout i guess), which WWW::Mechanize::Firefox "takes into account" (simple words for beginner understanding).

I read it several times, i knew it but forgot it while doing this first test. I guess i hoped there could be a (bijective) correspondence between the two. And i made this mistake also because i was doing this first test on an example where there is no Javascript at all.

Next step for me : learn about XPath.
From what i remember it looks fairly much like a Tree. So i guess i could use similar algorithms. Any major difference ?

Thanks again for helping me understand :o)
Now i know where to look, which makes a big difference.

XPath is "just" a query language for trees. When starting out with XPath, I found the analogy to paths in a directory tree helpfull. "*" works the same, "/" works the same. If you don't care about the intermediate directories, use //.

Thank you ! Same algorithms, other language. Should be fairly simple =o)

In my searches on internet, i found that Mozilla::Mechanize seems to do this another way. The elements it returns are Mozilla::DOM::HTMLElement, and it gets their position thanks to a QueryInstance.
I don't know what a DOM:HTMLElement are, nor QueryInstance. I don't have the time to learn these now, and know that i want to use WWW::Mechanize::Firefox, so i could as well forget about it for now.

I was just wondering if it was equivalent to using XPath in the end, and if a few words could make me understand.
If not, it's all alright : i now know i should use XPath.
And if i need to understand these, i'll read a book about it.