Martin von Gagern Reporter
	Description • 20 years ago

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040729
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040729

When loading a https:// source into a frame, otherwise staying on the same
server, the links in this page that target other frames do not work. Opening
them in a new window / tab works fine.

Reproducible: Always
Steps to Reproduce:
1. Open Frameset
2. Open secure page in one frame
3. Klick on link (http or https does not matter) targeting other frame

Actual Results:  
nothing happens

Expected Results:  
link should be opened in other frame

	Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com]
	Comment 1 • 20 years ago

timeless says it is probably caused by the fix for bug 246448, so this behavior
is expected.

	timeless
	Comment 2 • 20 years ago

i'm not sure about expected, predictable ...

	Gervase Markham [:gerv]
	Comment 3 • 19 years ago

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

	Martin von Gagern Reporter
	Comment 4 • 19 years ago

This is still a problem with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12)
Gecko/20051005 Firefox/1.0.7.

As long as noone argues that this is indeed intended behaviour for some reason
or other, which I frankly don't believe, this is still an open bug, easy to
confirm, and should be solved one day.

	Christian :Biesinger (don't email me, ping me on IRC)
	Comment 5 • 19 years ago

could you also test using a build from the provided links, instead of in 1.0.7?

	Tony Mechelynck [:tonymec]
	Comment 6 • 17 years ago

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008060101 SeaMonkey/2.0a1pre

Either link triggers the display of a XUL error page, which is always displayed in the top frame (see text at the bottom of this comment), so this testcase WFM by respect to the "link targeting other frame does nothing" error.

Here's the text of the error page:

Secure Connection Failed

www.fs.tum.de uses an invalid security certificate.
The certificate is not trusted because the issuer certificate is not trusted.
(Error code: sec_error_untrusted_issuer)
    * This could be a problem with the server's configuration, or it could be someone trying to impersonate the server.
    * If you have connected to this server successfully in the past, the error may be temporary, and you can try again later.

          Or you can add an exception…

	u279076
	Comment 7 • 16 years ago

https://litmus.mozilla.org/show_test.cgi?id=7775

I've added the above test case to litmus for this bug.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090602 Shiretoko/3.5pre and Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1pre) Gecko/20090602 Shiretoko/3.5pre both WFM, as I suspected as this is an OLD bug.

Resolving WFM.