GNOME Bugzilla – Bug 335226
Bug: opens wrong links when searching through pages
Last modified: 2008-03-20 14:53:54 UTC
That bug has been described on https://launchpad.net/distros/ubuntu/+source/epiphany-browser/+bug/34671 "This is a rather annoying bug, and it's rather difficult to explain. I guess it would be best shown through an example. Here's steps to reproduce this bug: 1) open up distrowatch.com 2) use ctrl-f and select different links, and middle click them. Unusual behavior: Many times, when you middle click a link to open it in a new tab, the page will scroll up and the wrong link will be opened. This bug is not only for distrowatch, but many other pages. I wish I could be more clear on why this is happening, but I'm not sure. Can anyone else confirm this?"
I'm possibly seeing the same behavior. Lots of times when I am reading a long page and middle click on links, instead of opening a tab, the page will scroll back up, possible back to the last link I clicked on. I do not have to ctrl-f to cause this behavior. I am running Ephiphany 2.14.1 on Dapper beta, but have been experiencing this behavior for a while.
The behaviour of this bug seems to be like this: if a link is focused in the main browser window, and the viewport has been scrolled WHEN the find bar is active (use "find next" button, or Ctrl-G), then when a link is clicked, the viewport scrolls back to the previous focused link before the click event is handled, and an incorrect link is followed. Most easily demonstrated with mailman archive pages. It only happens when the Find bar is open - using Ctrl-G to change the viewport when the Find bar is closed will not cause the problem to appear.
I confirm this one. This is a long standing one. It can be easily reproduced but, strangely, it doesn't happen always. Sometime (not often), it works...
*** Bug 345185 has been marked as a duplicate of this bug. ***
From the bug report of bug #351089 (markes as duplicate since this bug has some comments and the other one doesn't): While searching in a document, click in the document (e.g. a link) scroll up to the focused element (e.g. a previously clicked link). User has to blur element (clicking on a non focusable element) and continue to search. Steps to reproduce: 1. It's easier to reproduce the bug in long link list like http://cvs.gnome.org/viewcvs/ 2. Search e.g "print" (Ctrl+F ; "print") 3. Middle click to a link 4. Search next occurence (Ctrl+F ; Enter) 5. (Middle) click another link Actual results: The document is scrolled up to the first clicked link. The second link is not followed. Expected results: I expect epiphany to correctly follow the link. Does this happen every time? Yes Seems like the same problem with a slight modification, maybe this helps clarify the problem.
*** Bug 351089 has been marked as a duplicate of this bug. ***
*** Bug 358998 has been marked as a duplicate of this bug. ***
It doesn't revert only to previously selected links, it also scrolls up to blank spaces. Watch it happen in this screencast: http://img183.imageshack.us/img183/373/1tm3.gif
Thanks David, that's pretty much the best "Steps to reproduce this" that I have ever seen :).
Forgot to say: Any ideas on why does this happen?
Reading Bug #409635 I came to suspect this might be something related to ephy-link magic. Note that the page jumps exactly to the previously selected/focused link when you are _activating_ a link. Makes me think that maybe Ephy still thinks that the currently focused link is the previous one. So when you emit the "clicked-go-here" signal when clicking the link you are actually telling Ephy to activate the selected link, that because of this bug is the previous one. Bug #409625 report: 1. Go to a page which needs vertically scrolled; for example, http://news.google.com. 2a. Select a link near the top of the page, but do not click it. This can be achieved by putting the mouse button down on the link, dragging the mouse, then releasing the button. 2b Instead of 2a, you could click with the mouse in a textbox near the top of the page. 3. Show the Find panel (Ctrl+F). 3. Scroll down the page without clicking on the page (e.g. with a scrollwheel, or by using the Find feature). Now, click any link.
*** Bug 342558 has been marked as a duplicate of this bug. ***
It's not caused by EphyLink, it's caused by the gtkmozembed focus bug fix/work-around. The window's focus controller is inactive while the find bar is shown (since the find bar has focus), and when the embed regets the focus, it tries to jump to the focused content.
*** Bug 426517 has been marked as a duplicate of this bug. ***
*** Bug 445920 has been marked as a duplicate of this bug. ***
It also occurs when you focus on the address bar, then scroll, then click back on the Mozilla bit. I was wondering if the nsIWebBrowserFocus interface could be used to solve this bug. The Mozilla docs for nsIWebBrowserFocus::deactivate() say: "it should also be called when focus moves from the browser to the embedding chrome." This made me think that calling it when the Find toolbar or the address bar get focus (and then adding the corresponding calls to activate()) would solve the problem. Then again, gtkmozembed probably already does this.
*** Bug 447992 has been marked as a duplicate of this bug. ***
I noticed that if you scroll down to the bottom of the page, the problem goes away (for that page only). Does this help in finding the solution? I've got an svn copy of the source and could hack away under some guidance if you think this is suitable to be tagged with gnome-love.
Created attachment 93091 [details] [review] patch from ML, by Iain Nicol The patch looks right, at first glance. I'll adapt it to trunk when I next update my gecko build.
(and we might want to get an usptream bug too)
*** Bug 471783 has been marked as a duplicate of this bug. ***
It was *very* painful, but I eventually managed to build Epiphany against xulrunner trunk. Managing this, I updated the patch (it still seems to work, and it's still necessary). Then I forwarded the bug upstream: <https://bugzilla.mozilla.org/show_bug.cgi?id=396652>.
[Building epiphany against xulrunner trunk isn't really supported yet. I'm working on the new xulruner backend (configure: --with-engine=xulrunner) but it's not yet ready for use (crashes a lot).]
This has now been fixed upstream, in Mozilla trunk. Which means this bug will disappear for end users in the future when distros build Epiphany against Mozilla 1.9. Of course, you might not wish to take my word for it ;).
Great. Closing. Kudos to you!
Should this patch be added to http://live.gnome.org/Epiphany/MozillaPatches ?
I'm not sure the latest patch applies to the gecko 1.8 branch. Also the next round of distros are probably going to use 1.9 already...
*** Bug 485511 has been marked as a duplicate of this bug. ***
*** Bug 499411 has been marked as a duplicate of this bug. ***
*** Bug 523563 has been marked as a duplicate of this bug. ***