Tags:
create new tag
, view all tags
Just want to start recording some RFEs for Internet browsers. The best one (IMHO) (the Mozilla supervisory program) is:
  • somewhat difficult to explain
  • partially implemented in various options on many browsers -- I want to list the features that already exist that should be incorporated in my suggestion, but I somehow need to put the focus on the new features (or the "synergistic" combination of features)

Aww, son of a gun ;-), just saw somebody with the germ of my "brilliant idea" (borfast <borfast@yahoo.com>, on 14 Sept 2002, and he refers to "just like Opera does"). Oh well, I'll still come back here and write it up anyway -- I think I have a few new wrinkles anyway. (Not that I care that much about credit -- but I'd still like to find a way to earn a living with Linux.)

See AboutThesePages.

Contents

Mozilla Monitor Program

(This suggestion is driven by my experiences with Mozilla 0.9.8 -- it's possible that something similar has been already implemented in a more recent version.)

Background: Mozilla crashes. (Note: All programs crash, probably never totally stop that.)

Therefore: Provide a Mozilla "supervisor" program with the following characteristics:

  • Not part of the Mozilla executable (so it is unlikely to crash when Mozilla does)
  • It can start after Mozilla and obtain the necessary system status (stati?) (more later) from running instances of Mozilla, so that, if the supervisor does crash and Mozilla doesn't, the supervisor can recover. (This is lower priority than other "core" features.) (Also that data is stored persistently, so there is an option of recovering the data from the persistent store (boy, I like using such a long phrase instead of saying file wink ), or from the running instances of Mozilla -- might need a reasonable way to mix and match, like get everything from the persistent store, then selectively add data from open Mozilla windows.)
  • Keeps a record of all relevant information about running (and perhaps stopped / closed) windows / tabs of Mozilla, including:
    • Current status of window/tab (which desktop, tab part of which window, URL displayed, page or line?, name of local cache of this URL)
    • <more?>
  • In the event of a Mozilla crash (which typically takes out all open windows and tabs of Mozilla including mail (and probably news, composer, etc.), the supervisor can restart all of those instances in their "original" windows. On the other hand, it can selectively restart only desired windows (to avoid the problem if one of the windows (pages) is causing the crash).
  • It collects "real time" data about the operation of Mozilla on a continuous basis -- one focus is to try to identify which window was doing what when a crash occurred (might set a flag for a window when you start to load a page, clear it when you're done, if flag is set during recovery supervisor should recognize that this page might have caused the crash and give the user a chance to avoid loading it.
    • Similarly, it might keep track of how many tabs were open in each of how many windows and how much memory and cpu was being used by Mozilla (at intervals) then display this information for the user at any time including during recovery. Also, how much free and used memory, swap, and buffers (or whatever) at those same snapshot intervals.
  • In conjunction with this (I think I said this already) it should know the location of all recent cached pages and should restore pages from cache and then go out on the internet to refresh them. Might be a user selectable thing for each page, and have status indicators on the supervisor "window" (did I mention the supervisor status window yet? wink ) showing which windows are fully restored and which are only restored from cache.
  • This supervisor status window will be available, easily displayable, and usable when Mozilla is up and running find to show which windows are loaded, which are loading, which URLS, etc., and maybe provide a "dynamic grouping" feature. (I'm looking for pages on a few topics, anytime I request a URL (new tab / window or existing) it allows me (or it automatically, if feasible) puts that request in a category for grouping on the supervisor status window (maybe I want to delay reading any page on a subject until I know that all are available, or something of that nature).

Minor RFEs / Bugs

Focused specifically at Mozilla 0.9.8 on Mandrake 8.2

I started reviewing some of the Mozilla developer newsgroups / mail lists -- it was gratifying to see some of the same complaints I have mentioned (netscape.public.mozilla) (Parsing of that last sentence can be ambiguous -- I did not mention my complaints there, it was gratifying to see others have the same complaints and have mentioned them there.) PS: Why are the user newsgroups secure?:

End-user discussion and peer support: snews://secnews.netscape.com:563/netscape.mozilla.user.general snews://secnews.netscape.com:563/netscape.mozilla.user.win32 snews://secnews.netscape.com:563/netscape.mozilla.user.mac snews://secnews.netscape.com:563/netscape.mozilla.user.unix

  • When KMail or KNode opens a URL in Mozilla, it should open in a new tab or window (user selectable) and not overwrite some existing page. (Update: apparently there is a user preference that can help with this -- add to user.js: |user_pref("advanced.system.supportDDEExec",false);| -- not sure if the pipes ("|") are significant -- found this on a newsgroup post by Brian Heinrich <humbug@myrealboxXXX.com> on netscape.public.mozilla.wishlist.)

  • Maybe this helps also: //force 'target="_blank"' to load in same browser window (allowing you to open it in a tab):
user_pref("browser.block.target_new_window", true); to user.js. (From Brian, again.)

  • When a URL fails to open in Mozilla the URL should stay in the address bar so it can be retried. (Update (from Brian again): "That you can't do ( . . . yet . . . ), but you can force it to open in a new window; adding |user_pref("advanced.system.supportDDEExec", false);| to user.js (a user-created text file in the same directory as prefs.js) should do the trick."

  • Provide methods to wrap lines at the width of my window even if the site doesn't want to wink (to improve readability)

  • Aside: See what <ctrl D> does in IE -- <ctrl L> might do the same thing in Mozilla.

  • (Mozilla) Magnification should be persistent in some rational ways -- two initial thoughts -- if I set a magnification ratio in one window, set the same ratio for: any subsequent pages called up in the same window, and any pages opened in another window or tab from that window. (It's no worse than having them all 100% by default, is it wink ). (And Konqueror 2.2.2 needs a magnification ratio.)

*

Focused specifically at konqueror (3.1.1 on Knoppix 3.2)

  • konqueror needs a magnification ratio — the increase and decrease font size approach just is not as usable:
    • small and unpredictable increments in size
    • limited increments
    • doesn't affect the entire page the same way (like magnification ratios do in other browsers)

  • need a way to know which instance of konqueror is associated with which Linux PID (firstly to deal with situations where one instance (the window or a particular tab is using excessive resources (memory or CPU) — I want to look at top and see which PID is the problem, then look at the tabs in that instance of konqueror and selectively close some to see if I can improve performance. Until now, it's a trial and error thing. Maybe one ideal UI idea is to have each browser window display it's PID (or optionally by right clicking or similar) (A similar thing would be nice for Mozilla, but since running more than one truly independent instance is difficult at this time, it is more problematical.)

See:

Notes

Resources

See ResourceRecommendations. Feel free to add additional resources to these lists, but please follow the guidelines on ResourceRecommendations including ResourceRecommendations#Guidelines_for_Rating_Resources.

Recommended

  • (rhk) [[][]] --

Recommended for Specific Needs

<Currently, no significant content below this line.>

Recommended by Others

  • (rhk) [[][]] --

No Recommendation

  • (rhk) [[][]] --

Not Recommended

  • (rhk) [[][]] --

Contributors

  • () RandyKramer - 13 Sep 2002
  • <If you edit this page: add your name here; move this to the next line; and include your comment marker (initials), if you have created one, in parenthesis before your WikiName.>

[[Main.RandyKramer#13 Sep 2002][]]

Page Ratings

Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r7 - 2003-08-30 - RandyKramer
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by PerlCopyright 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding WikiLearn? WebBottomBar">Send feedback
See TWiki's New Look