Closed Bug 195078 Opened 22 years ago Closed 20 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: 20 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: