"Show Only This Frame" should prevent forced reframing

NEW
Unassigned

Status

()

Core
General
P5
enhancement
16 years ago
5 years ago

People

(Reporter: Cesar Eduardo Barros, Unassigned)

Tracking

({helpwanted})

Trunk
Future
helpwanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.1+) Gecko/20010622
BuildID:    2001062212

Some pages use JavaScript to force the user into a frame. "Show Only This Frame"
should prevent this reframing.

Reproducible: Always
Steps to Reproduce:
1. Go to the site
2. On the largest frame (the one on the top, with the _real_ content) select
"Show Only This Frame" from the context menu

Actual Results:  The frameset came back

Expected Results:  Mozilla should have pretended the page was still in the
frameset (i.e. the frameset is still there, we're just showing only one of the
frames and not even bothering to load the rest of them). Or do some hairy evil
thing which would never work quite right to prevent any kind of frameset-forcing
JavaScript. The first option is probably better.
this is already filed
Whiteboard: DUPEME

Comment 2

16 years ago
Do you mean bug 81084?
I do indeed.  Thanks, doctor__j@hotmail.com

*** This bug has been marked as a duplicate of 81084 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
Hmm.  Read this again.  Reopening.  The idea here seems to be to change the
implementation of "show only this frame" to resize frames instead of loading the
document in the frame in the full browser...  That might actually be a decent
idea, assuming that context menu problems are ironed out.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Over to XP apps.
Assignee: mstoltz → pchen
Status: UNCONFIRMED → NEW
Component: Security: CAPS → XP Apps
Ever confirmed: true
QA Contact: ckritzer → sairuh
Whiteboard: DUPEME
see this on mac and winnt [comm branch] bits as well.
OS: Linux → All
Hardware: PC → All
I think this is in fact a dupe of 81084, but this oes seem like a reasonable
approach if someone wants to implement it. We need to think it through though.
What would ahppen to the "hidden" frames when the user clicks away from that page?
Severity: normal → enhancement
Summary: "Show Only This Frame" should prevent forced reframing → [RFE]"Show Only This Frame" should prevent forced reframing
(Reporter)

Comment 8

16 years ago
What happens to normal frames.

There's no real difference, you're still there within a frameset; _top will kill
them, and targeting the current frame keeps them. Targeting another frame moves
your point of view to that frame.
marking p5, future, and helpwanted
Keywords: helpwanted
Priority: -- → P5
Target Milestone: --- → Future

Comment 10

16 years ago
*** Bug 82256 has been marked as a duplicate of this bug. ***

Comment 11

16 years ago
-> default assignee
Assignee: pchen → trudelle
Target Milestone: Future → ---

Updated

16 years ago
Target Milestone: --- → Future

Comment 12

15 years ago
Mozilla could bring the frame to the top without re-parsing the page.  That
would make "show only this frame" faster and more accurate while at the same
time ignoring forced-reframe scripts (which are intended to fix external links,
not to annoy visitors).  Opera avoids re-executing javascript for back and
forward but surprisingly gets this case wrong.
Blocks: 86194

Comment 13

15 years ago
my 2 cents: just redisplaying the frame, without triggering onload or the like
seems like the better idea. With "Show only this frame", I expect that the other
frames are *gone*, that this frame is liek a normal page from now on, but that
the frame doesn't reload or anything like the current implementation seems to
do. Not sure, how difficult that would be to implement.

Updated

15 years ago
Component: XP Apps → XP Apps: GUI Features
Summary: [RFE]"Show Only This Frame" should prevent forced reframing → "Show Only This Frame" should prevent forced reframing

Comment 14

15 years ago
Mass moving all of my open Nav/toolkit bugs to new owner.
Assignee: trudelle → sgehani

Comment 15

13 years ago
Previous test URL was dead, replacing with one that works.

Prog.

Product: Core → Mozilla Application Suite

Updated

9 years ago
Component: XP Apps: GUI Features → UI Design

Comment 16

8 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED

Comment 17

8 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 18

8 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 19

8 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 20

8 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 21

8 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 22

8 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 23

8 years ago
This is an enhancement request (with 9 votes!).  Enhancement requests do not expire.
Status: UNCONFIRMED → NEW

Comment 24

8 years ago
Why has the exact same comment been posted 7 times?

Comment 25

8 years ago
That was a bug in Bugzilla, more or less.

Comment 26

8 years ago
SeaMonkey team can't fix this, I see this as WONTFIX in SeaMonkey-specific terms, but I'll let you keep it alive elsewhere, this belongs somewhere into Core but I have no clue where.
Assignee: samir_bugzilla → nobody
Component: UI Design → General
Product: SeaMonkey → Core
QA Contact: bugzilla → general

Comment 27

8 years ago
Many link agregating pages uses (i)frames to view submited links -> submited page in big frame and footer/header frame with some social options, ads, etc. Many portals didin't like that and used JS to jump out from frame. Just now I saw link agregate that prevents pages to break free from frame:
<script type="text/javascript">
    var prevent_bust = 0  
    window.onbeforeunload = function() { prevent_bust++ }  
    setInterval(function() {  
      if (prevent_bust > 0) {  
        prevent_bust -= 2  
        window.top.location = 'http://linkagregate.com/someurl.php'
      }  
    }, 1)  
</script>
The issue is that this JS code also prevents "Show only this frame" from working at all (FX 3.5.7). Implementing "Show only this frame" as "hide other frames" would help but real solution would be option to block onbeforeunload(). Sadly it is also used by legitime uses like some AJAX apps.
You need to log in before you can comment on or make changes to this bug.