Closed Bug 253961 Opened 20 years ago Closed 15 years ago

link does nothing when target is other frame and mixing HTTP and HTTPS

Categories

(Core :: Security, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: Martin.vGagern, Unassigned)

References

()

Details

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
timeless says it is probably caused by the fix for bug 246448, so this behavior is expected.
Component: Browser-General → Security: General
i'm not sure about expected, predictable ...
Depends on: 246448
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/
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.
could you also test using a build from the provided links, instead of in 1.0.7?
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…
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.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Flags: in-litmus+
Resolution: --- → WORKSFORME
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.