246392 - Reloading a page containing frames goes back to top level

Status: RESOLVED FIXED

(Core Graveyard :: Embedding: GTK Widget, defect)

Description

[Crispin Flowerday (not receiving bug mail)]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a2) Gecko/20040611 Galeon/1.3.15.99
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a2) Gecko/20040611 Galeon/1.3.15.99

If you load a site containing frames, and click a link which changes the content
of one of the frames, pressing reload takes you back to the top of the site

Reproducible: Always
Steps to Reproduce:
1. Start TestGtkEmbed
2. Open the testcase
3. Click on a the link to navigate into the site
4. Click on reload

Actual Results:  
The toplevel page in the main frame is reloaded rather than the page opened
after clicking on the link

Expected Results:  
The page that you navigated to should be displayed, just like in mozilla-the-browser

Originally reported as bug http://bugzilla.gnome.org/show_bug.cgi?id=66998

Comment 1

[Crispin Flowerday (not receiving bug mail)]

Attachment: Proposed patch

mozilla-the-browser uses the SessionHistory to perform the reload, rather than
the webnavigation, see
http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/browser.js#60


This patch mimics that code for the embedding widget

Comment 2

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 150594 [details] [diff] [review]
Proposed patch

sr=shaver

Comment 3

[Crispin Flowerday (not receiving bug mail)]

Comment on attachment 150594 [details] [diff] [review]
Proposed patch

It would be great if this could also get into the 1.7 branch. It only affects
the gtk embedding component, so is low risk, and is highly visible for users of
the widget (such as galeon and epiphany)

Comment 4

[Mike Kaply [:mkaply]]

Comment on attachment 150594 [details] [diff] [review]
Proposed patch

a=mkaply for 1.7.3

Comment 5

[Crispin Flowerday (not receiving bug mail)]

Attachment: Patch for 1.7 branch

This is the patch for the 1.7 branch, with the spacing corrected.

Comment 6

[Frédéric Buclin]

This bug is getting the approval1.7.3+ flag without being confirmed??? Why still
UNCONFIRMED?

Comment 7

[Crispin Flowerday (not receiving bug mail)]

Mainly because I have always been led to believe its not good form to confirm my
own bug, and no one else has been bothered....

Comment 8

[Frédéric Buclin]

(In reply to comment #7)
> Mainly because I have always been led to believe its not good form to confirm my
> own bug, and no one else has been bothered....

Well, blizzard or shaver could do it as they super/reviewed your patch. Or do it
yourself so we can see your bug when querying the database without UNCONFIRMED
being selected.

Comment 9

[Crispin Flowerday (not receiving bug mail)]

Thanks very much to timeless for checking this patch in, it is in both the 1.7
branch and trunk.