Slashdot Mirror


Mozilla 0.9.7 Released!

Chezypewf writes: "The newest release from the Mozilla Dev team is out. This milestone features basic S/MIME support, favicon support and the Document Inspector, a tool to inspect and edit the live DOM of any web document or XUL application. You can grab it here: http://www.mozilla.org/releases "

6 of 436 comments (clear)

  1. Re:Mozilla obsolete by asa · · Score: 4, Insightful

    kazaa.com has lame browser sniffing:

    //redirect for people with a less than
    //version 4 browser
    var NS4 = (document.layers);
    var IE4 = (document.all);
    var ver4 = (NS4 || IE4);
    if(!ver4)
    location.href= "notsupported.htm";

    and hotmail.com works just fine for me on mac, windows and linux mozilla 0.9.7 builds.

    --Asa

  2. Re:Well go ahead, got any better ideas? by Chuck+Messenger · · Score: 4, Insightful

    If you have a better idea of what to label that checkbox, I'd be glad to read it -- there's been a lot of suggestions so far, but they've all been either too wordy, too obscure, or (as in your case) just plain wrong.


    How about "Enable pop-ups/pop-unders"?

    I think that would neatly capture the intent of this checkbox. In fact, what would be particularly nice about it is that, as time goes on, and other means are developed for defeating "pop-ups" (whatever people come to understand that to mean), it would be possible to roll that functionality into that pre-existing checkbox.

    Actually, here's what I _really_ think. You should leave all that fine-grained JavaScript control stuff as it is, and where it is (under Advanced). What is needed is an "enable pop-ups/pop-unders" checkbox in, say, the main navigator preferences screen. This is a "digestified" function, i.e. it may do various things, which are not precisely-defined, but whose intent is to defeat what people commonly refer to as "pop-ups" or "pop-unders".
  3. Re:Well go ahead, got any better ideas? by The+Pim · · Score: 3, Insightful
    Can't resist adding my 2c.

    All of the entries after the first (I'm going by what the poster wrote; I haven't run 0.9.7 myself) can be read as if prefixed with "Scripts are allowed to ...". So make that the heading! "Scripts and Windows" makes little sense, since most of the entries are unrelated to windows. This change would require that "Enable Javascript" be moved to its own section, which seems appropriate anyway.

    (I guess someone wanted "windows" in the heading so that people looking to disable ad windows would see it; but this is "advanced" configuration, and I think anyone going here would know that it's really a script preference.)

    On to the original matter: "Open windows by themselves" is gratuitously ambiguous. "by themselves" seems to go with "windows", which could either mean that windows open in a separate part of the screen ("by" as in location"); or that windows spontaneously open without external cause ("by" as in agent). Neither one is really right.

    If you change the heading as I suggest, it reads, "Scripts are allowed to open windows by themselves". This is an improvement, because "by" as in agent clearly refers to "scripts". But the "by" as in location interpretation is still possible, so it remains confusing.

    "Scripts are allowed to open windows automatically" reads with no ambiguity to me, and seems no worse in any way. So I would suggest "Open windows automatically" as the text for the checkbox. "Open windows without user input" isn't bad if you want to be more explicit.

    --

    The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
  4. Re:Well go ahead, got any better ideas? by slamb · · Score: 4, Insightful

    Well, if you have any suggestions, do share them.

    I don't like the options stated here:

    Scripts and Windows
    x Enable Javascript
    x Open Windows by themselves
    x Move or resize existing windows
    x Make windows flip over or under other windows
    x Change status bar text
    x Change Images
    x Create or change cookies
    x Read cookies

    I propose instead:

    Scripts and Windows
    x Enable Javascript
    Javascript code may:
    x Open windows on page load/unload (pop-up and pop-under ads)
    x Move and resize existing windows
    x Change window ordering (pop-under ads)
    x Change status bar text
    x Change images (mouseover highlighting)
    x Create and change cookies
    x Read cookies

    First, the other options definitely belong as a sub-item as the first one, disabled when it gets disabled. (If it's actually this way in the dialog, sorry, my Mozilla isn't quite new enough to have your feature. I'm going by the bug report.) There should be a little label to explain the wording of the subitems, since they are stated as what the code is doing ("open a window") rather than what you're doing ("allowing them to open a window").

    Second, I really don't like the "by themselves". Obviously everything in Javascript happens because of some event firing. I think on page load/unload is more clear. (Or some other way of precisely stating what events you're talking about.)

    Third, it has in parenthesis a common use of several features. This should give a better understanding of what you'll be breaking.

  5. VIEW SOURCE still sucks by mgkimsal2 · · Score: 5, Insightful

    It *seems* that when I "view source", the browser hits the server to download another copy. I don't WANT *another* copy - I want to the see the source of what is being rendered in the browser. With many web-based apps, doing another request (especially without resending the proper POST info, etc) will give back different results.

    The same behaviour was a huge problem for printing in Netscape. Rather than print what was in the browser's memory and on the screen, netscape would do a GET request on the URL. If it didn't come back with the right results - oh well! Too bad...

    Why on earth can't we simply see what's in the browser's memory already? It seems this is the EASY thing to do and Netscape (and now Mozilla) are unnecessarily complicating the matter.

    1. Re:VIEW SOURCE still sucks by BZ · · Score: 3, Insightful

      > I need the source of WHAT THE BROWSER IS SHOWING
      > AT THIS MOMENT IN TIME

      Which, with client-side scripting involved, has nothing to do with the source that was served from the website (consider a page that dynamically creates and appends some elements.

      The fact of the matter is, there is no good reason to keep the source once it has been parsed, so Mozilla do it. The only place the source stays is in the cache. Thus the problem becomes one of extracting the correct cache entry.

      And Mozilla always prints exactly what you see; it prints based on the DOM, not on the source.