Closed Bug 195078 Opened 22 years ago Closed 21 years ago

Gecko provides the wrong URL when rendering Framset

Categories

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

Product:
Core Graveyard
Component:
Embedding: GTK Widget
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: christophe, Assigned: blizzard)

References

(
URL
)

Details

Attachments

(1 file, 1 obsolete file)

patch with formatting fixes and a little clearer comment
1.34 KB, patch
blizzard
: review+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.3b) Gecko/20030130 Build Identifier: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.3b) Gecko/20030130 All recent browsers based on gecko are hit by this bug. Basically when rendering a Frameset, gecko provides to the browser the URL of the last frame instead of the URL of the page containing the Frameset. This is a problem when user reload the page. They reload the last Frame instead of the whole set. I have verified this bug on Chimera under MacOS X, galeon 1.3.1 and Epiphany under Linux. Galeon 1.2.7 at least the one available in debian/unstable is not concerned by this bug but is linked against an older mozilla (1.1). Mozilla itself is not concerned by this problem. With the following 3 files, if you open index.html and click the link, the link is correctly opened in the frame main but the URL of the frame is displayed in the URL bar instead of index.html. You can also see this test case at http://cattlegrid.net/~christophe/chimera/ <-- index.html --> <html> <head> <title>Simple frame/target test</title> </head> <frameset cols="100%" rows="100%" border="0" frameborder="0" framespacing="0"> <frame src="test1.html" name="main"> </frameset> </html> <-- test1.html --> <html> <head> <meta name="AUTHOR" content="christophe barb&eacute;"> <base target="main"> </head> <body> <p>The URL in the browser should be index.html</p> <p>Click <a href='test2.html'>here</a> to continue the test</p> </body> </html> <-- test2.html --> <html> <head> <meta name="AUTHOR" content="christophe barb&eacute;"> <base target="main"> </head> <body> <p>The URL in the browser should still be index.html</p> <p>Click <a href='test1.html'>here</a> to go back</p> </body> </html> Reproducible: Always Steps to Reproduce: 1. 2. 3.
I can't reproduce problem with your testcase under any of the following. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030222 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030208 Phoenix/0.5 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 Your testcase works as intended. The index.html is still in Location bar. :)
All browsers I have tried use an older Gecko engine. No newer mozilla is available in debian/sid so I can't confirm that the bug has been fixed with galeon and phoenix is not available for powerpc. But I just tested it with the latest nightly buit of Chimera and see the same problem: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030225 Chimera/0.6+ Marco Pesenti Gritti (The original author of Galeon and author of Epiphany) seems to think that the bug is a Gecko bug: http://bugzilla.gnome.org/show_bug.cgi?id=106945 I don't understand why mozilla himself does it correctly when galeon and epiphany build using the same gecko engine have problems.
Because it's a bug in Chimera, sounds like (getting the URL from the wrong place, most likely).
Assignee: asa → saari
Component: Browser-General → General
Product: Browser → Chimera
QA Contact: asa → winnie
Version: Trunk → unspecified
That's what I thought first but the same bug appears in galeon and epiphany. So it looks like something is wrong in Gecko. Note that I have already filed a bug against Chimera: http://bugzilla.mozilla.org/show_bug.cgi?id=194251
It's possible that the embeddors in question are all making the same mistake, you know.... Since there is already a Chimera bug, sending this to embedding APIs, but it would be good to know how those embeddors _think_ they're supposed to be getting the current URI.
Assignee: saari → adamlock
Component: General → Embedding: APIs
Product: Chimera → Browser
QA Contact: winnie → carosendahl
Version: unspecified → Trunk
If this is a Gecko bug, we would see this in MFCEmbed too, right?
The "bug" could be as simple as a poorly documented interface.... This is why we need to know how Chimera &co go about getting the current url.
I tested this is in the 2/25/2003 nightly of MFCEmbed and it did not have this problem. It properly navigated the frames and reloaded the main frameset when requested. It looks like the bug should be retargeted to those specific applications that are experiencing this problem.
The bug is reproducable in TestGtkEmbed. If it's not an API bug I think it should be move under gtkmozembed component.
ah, there we go. That sounds like a lead. ;)
Assignee: adamlock → blizzard
Status: UNCONFIRMED → NEW
Component: Embedding: APIs → Embedding: GTK Widget
Ever confirmed: true
QA Contact: carosendahl → pavlov
*** Bug 194251 has been marked as a duplicate of this bug. ***
camino gets the url from the OnLocationChange() callback of the nsIWebProgressListener. we pass it straight up to the url bar. is there code in mfcEmbed to only do this on the toplevel of a frame or something?
As I understand it, yes.
(In reply to comment #7) > The "bug" could be as simple as a poorly documented interface.... This is why > we need to know how Chimera &co go about getting the current url. We [Epiphany] connect to gtkmozembed's "location" signal and use gtk_moz_embed_get_location() in the callback to get the new url. I've checked mfcembed, and they do check if the location change is on a subframe and only set the new location in the UI if not, see http://lxr.mozilla.org/seamonkey/source/embedding/tests/mfcembed/BrowserImplWebPrgrsLstnr.cpp#105 . I'm going to attach a patch with that bit of code ported to gtkmozembed to only emit the signal and store the new location when the load is in the toplevel. This will change the behaviour of gtk_moz_embed_get_location() to always return the toplevel url, whereas now it returns the location of the last subframe location change -- is that acceptable?
Attachment #143628 - Flags: review?(blizzard)
No functional changes from the previous patch, just cleanup. Thanks!
Attachment #143628 - Attachment is obsolete: true
Attachment #143628 - Flags: review?(blizzard) → review-
Attachment #146122 - Flags: review+
Chris, you'll land this, right?
Yep, sure will.
Excellent. Thank you!
Checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Keywords: fixed1.7
I am right in thinking that mozilla/epiphany/chimera authors should adapt the patch to their source? Or was it a problem in gecko. Thanks for the fix, Christophe Barbe
I didn't check this into the 1.7 branch.
Keywords: fixed1.7
I don't think they have to implement it. It was really a problem with the widget.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: