Open Bug 47139 Opened 21 years ago Updated 13 years ago

Make page source tabbed, each tab representing a frame

Categories

(SeaMonkey :: UI Design, defect)

defect
Not set
normal

Tracking

(Not tracked)

People

(Reporter: bugzilla, Assigned: jag+mozilla)

References

Details

(Whiteboard: relnote-user)

Attachments

(1 file)

this has been around for a while, but i cannot seem to find an existing bug for
this problem. if it does exist, please do lemme know (would it perchance be bug
16632?)

anyhowusing the branch bits (tested on linux and mac today).

1. go to a page with frames, eg http://www.wired.com or http://marvin.mcom.com
2. click in the content area of one of the frames (to get focus).
3. dropdown the View menu.

observe that there are only entries for Page Source and Page Info.

side note: this is not a problem (well, sorta) for the context [popup] menu,
since View Frame Source *is* there. (page/frame info missing in context menu is
covered by bug 41443).
i doubt there's time to implement this for beta2, unless am being too
pessimistic --so adding relnote2 kw.
Keywords: relnote2
clarified summary.
Summary: View > Frame Source, Frame Info not yet implemented? → View > Frame Source, Frame Info not yet implemented in menubar?
me me me! I want it! all me!
Assignee: law → BlakeR1234
Status: NEW → ASSIGNED
Target Milestone: --- → M18
Matthew, we need some UI magic here.  What should the order of these items: 
{Page Source, Page Info, Frame Source, Frame Info} be in the menu?  In one 
sense, it's logical to group the two page and the two frame items together, but 
in another it's logical to group the two source and the two info items 
together...
4.0xp (but not 4.xp where x !=0, I think) is Page Source, Page Info, separator, 
Frame Source, Frame Info. And that makes a lot of sense, because frameless pages 
are much more common than framed ones, so the Page commands should go together 
more than the Source commands should.

Give me 24 hours on this one, I need to think. For some documents (e.g.
<http://rnz.co.nz/>) you have frame A inside frameset B inside frameset C. If you 
just provide `Page Source', `Page Info', `Frame Source', and `Frame Info', you're 
going to be able to get to the source or info of A and C, but never of B (unless 
you use Page Info to find B's URL and open B in its own window, but that isn't 
always possible with militant Web sites which insist on framedness).

See also <http://critique.net.nz/project/mozilla/general/components/info/>, which 
is the beginnings of combining Page Source, Page Info, Frame Source, and Frame 
Info (among other things) into a single `Document Properties' thingy. (If you
and Tim Hill implement that, you'll be worshipped by Web developers the world 
over ...)
Wouldn't Frame Source give you the source of whatever frame was currently
selected, thereby making it possible to get the source of any frame? (btw, that
site you mentioned doesn't load...bad JS UA check)

Also, in 4x, is the Frame Source item just missing entirely from the View menu
if the document has no frames, or just disabled?
> Wouldn't Frame Source give you the source of whatever frame was currently
> selected,

That's right.

>           thereby making it possible to get the source of any frame?

No. Because frame B is a frameset filled up with frames {A1, A2, ...}, you can't 
select frame B because you're always selecting one of the A frames instead.

This was a problem with 4.x too, of course. And if you're not worried about 
perpetuating a rare problem with nested frames (where the alternative is probably 
a popup menu for selecting frames in the Info window, combined with source 
display in the Info window ...), then just go ahead and copy the 4.0x menu items 
as described above.

> Also, in 4x, is the Frame Source item just missing entirely from the View menu
> if the document has no frames, or just disabled?

Probably disabled, but I don't have a version available to check. (Remember this 
is 4.0x we're talking about. In 4.5 and later, Frame Source/Info disappeared into 
the context menu.)
Ok, sorry for the delay.

The quick solution is to do Page Source, Page Info, separator, Frame Source, 
Frame Info, like 4.0x did. You won't be able to get to the source/info of the
B-type frames, but then no other browser that I know of lets you do that either.

The proper solution is to do the following:
* make View Source a tab of the Info window (with an `Edit ...' button to open
  the source in your helper app for text/plain);
* add a popup menu, above the tabs, to select which file you are showing the
  source/info for (where the default is `document', for the outermost frameset);
* replace the four menu items with a single `Document Source/_Info' item.
Not only would this provide access to the B-frames, but it would also simplify 
the menu to the order of three (!) items.
I was just thinking about this today.  We can't really have a View Frame 
Source/View Frame Info menu item if we're not going to show focus in frames 
(that bug got futured), since the user will really have no idea which frame the 
items refer to.
blake, what's the # of the doesn't-show-focus-in-frames bug?
[sorry 'bout delay...] That's bug 42758.  While I could still implement this 
(focus is given to frames, just not shown), I think it would just hurt things, 
since the user would have to guess most of the time which frame he's getting 
the info about or the source for.  so marking this dependent on 42758 and 
futuring it until we get a decision.
Depends on: 42758
Target Milestone: M18 → Future
Keywords: helpwanted
removing helpwanted, I already have a patch, it's just useless without 42758 
getting fixed
Keywords: helpwanted
Whiteboard: relnote-user
p5 until 42758 is fixed
Priority: P3 → P5
Assignee: blakeross → ben
Status: ASSIGNED → NEW
Component: XP Apps → XP Apps: GUI Features
Priority: P5 → P3
Target Milestone: Future → ---
giving this to Ben for now, I'll take it back when 42758 gets fixed.
Netscape nav triage team: per Alec Flett's pre-triage recommendation, this 
bug is nsbeta1-.
Keywords: nsbeta1-
Marking nsbeta1- bugs as future to get off the radar
Target Milestone: --- → Future
Blocks: 79518
It looks like 42758 is fixed now. Blake, do you still have your patch?
Blocks: 108099
taking
Assignee: ben → cbiesinger
Priority: P3 → P1
Target Milestone: Future → mozilla0.9.9
Status: NEW → ASSIGNED
Keywords: helpwanted
Comment on attachment 70089 [details] [diff] [review]
patch

accesskey will conflict with reload or something, otherwise this is fine
Attachment #70089 - Flags: review+
Attachment #70089 - Flags: needs-work+
what happened to the suggestion in comment #8?  I think it's a good approach to
keeping the menus short.  i would only propose that we do not combine Page Info
and Page Source into one tab-style panel,  but keep them separate features. 
this would allow us to do a tabbed panel on Page Source, where each tab would
represent one frame of the frameset.  So if a user is focused in a frame, then
choose command "view source" from the menu, it opens the panel pre-selected on
the focused frame.  this provides an easier inteface to accessing other
source(s) in case they did not really intend to focus a frame to view.

 
looks like I missed comment 8...

OK, well, I think that would be possible...
Seems to be not as simple, though, so setting Target Milestone = 1.0.1
Priority: P1 → P2
Target Milestone: mozilla0.9.9 → mozilla1.0.1
*** Bug 16632 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.0.1 → mozilla1.1alpha
resummarizing according to comment 22
Summary: View > Frame Source, Frame Info not yet implemented in menubar? → Make page source tabbed, each tab representing a frame
Target Milestone: mozilla1.1alpha → mozilla1.1beta
What about hitting CTRL+U when a spcific frame is in focus? Right now, it 
displays the source of the parent page, NOT the source of the focused frame.
well, if I'd change that, there would be no way to view the page source if 
you're currently viewing a frameset with the keyboard, only the frame source...

in any case, that's a seperate bug, though it would be made invalid with fixing 
this one.
Target Milestone: mozilla1.1beta → Future
bugs w/o patches -> NEW
Status: ASSIGNED → NEW
I have learned that UI patches are not wanted in this project. reassigning to
default owner.
Assignee: cbiesinger → blaker
QA Contact: sairuh → paw
Reassigning obsolete bugs to their respective Seamonkey owners (i.e. nobody). 
If you want this fixed for Firefox, change the Product and Component accordingly
and reassign back to me.
Assignee: firefox → guifeatures
Target Milestone: Future → ---
Product: Core → Mozilla Application Suite
could be a nice addition. 
patch is real simple, but needs to be reverified.
takers?
Filter "spam" on "guifeatures-nobody-20080610".
Assignee: guifeatures → nobody
QA Contact: pawyskoczka → guifeatures
Component: XP Apps: GUI Features → UI Design
Assignee: nobody → jag
Priority: P5 → --
QA Contact: guifeatures
You need to log in before you can comment on or make changes to this bug.