Mozilla 1.7 RC 1 ReleasedWednesday April 21st, 2004Asa wrote in to let us know that the first release candidate of Mozilla 1.7 has been released. Mozilla 1.7 reintroduces the Talkback crash reporting system, better GTK2 support, new popup blocking features, and a slew of other new features. A more complete list of changes in all components is available in the Mozilla 1.7 RC 1 Release Notes. Builds can be grabbed from the Releases page, or right from the FTP server. Mozilla 1.7 is the next stable product branch for Mozilla clients, and it's expected that Firefox 1.0 and a new Thunderbird version will be released off it later this year. Along with that, MozillaZine also expects a summer release of a rebranded Mozilla 1.7 as a Netscape 7.2. Update: Myk Melez wrote in to tell us that Mozilla 1.7 RC 1 can also be downloaded from the mozilla1.7rc1 directory on ftp.eu.mozilla.org, the European Mozilla FTP server. Anyone know if the problems with Flash under Linux is still there? In 1.6 (and firefox 0.8) under Linux (Fedora) any flash animations, etc. run really slow and choppy. Thanks -Jed You can try this workaround for GTK-2.x+ build of Mozilla / Firefox: (Someone may want to add this to the 1.7 release notes) http://www.pclinuxonline.com/modules.php?name=News&file=article&sid=8574 Even mozillaZine gets the new name wrong... :-) Actually I think while Firefox 1.0 is going to be based on 1.7 I think only Thunderbird 0.6 (and possibly 0.7?) will be using the 1.7trunk. "This release has a new SVG backend. The feature is not yet enabled in the mozilla.org releases but developers may wish to compile with this feature enabled." Was hoping at least a minimalist implementation of SVG support would hit the 1.7 branch. Yes, please enable SVG! Will it be turned on before the final? "Will it be turned on before the final?" In the official Mozilla release? Absolutely not! --Asa So, any plan or time frame when SVG will go into the main branch of Mozilla? 'So, any plan or time frame when SVG will go into the main branch of Mozilla?" SVG is already in the main branch of Mozilla (often called the Mozilla trunk). It's also in the Mozilla 1.7 branch. It's just not compiled in the Mozilla binary releases because it's not ready yet to be a part of the official build. --Asa What asa said. Also, see bug 122092 - Enable SVG support http://bugzilla.mozilla.org/show_bug.cgi?id=122092 The SVG bug I would like fixed most is bug 111496 - implement preserveAspectRatio http://bugzilla.mozilla.org/show_bug.cgi?id=111496 Otherwise the cute lion gets distorted: http://pms.colonpee.com/svg/lion.svg Bug 237845 is fixed. Should it be removed from the Know Issues section of Release Notes? Hello, haven't yet tested the RC1, but in the release note I did not notice any improvement on the eml import/export bugs in mozilla mail (in thunderbird too btw..). You still can save only one msg at a time, and won't be able to import them later? Alias has integrated Gecko in it's 3D Content Creation Programm Maya 6. Wondered if it was IE, but then read that is functioning most all platforms supported by Maya (Win, MacOX, Linux, (not IRIX)) http://www.alias.com/eng/products-services/maya/technical_features/api_sdk_mel.shtml quote: " Execute MEL Commands in the Embedded Browser* A Web browser, using Mozilla’s Java and JavaScript compatible Gecko rendering engine, is available within a Maya panel. It allows quick, convenient access to documentation and other online information, and enables technical artists to create Web pages that contain MEL scripts in the form of MEL URLs. It’s an easy way to extend the Maya user interface, create interactive Maya tutorials or manage assets and scene data. *(Windows, Linux, Mac OS X) " info: MEL is the Maya Embedded Language. there is a flash demo at http://www.alias.com/eng/products-services/maya/new/index.shtml#interaction showing the integration of MEL. Nice prove that Mozillas crossplatform capabilities are a big plus #17 still no paste images into email, bug 4 years old.by lkjhgfdsa Thursday April 22nd, 2004 3:38 AM http://bugzilla.mozilla.org/show_bug.cgi?id=47838 Promises of money to no avail you still can't paste a clipboard image into an email for a quick message. Netscape 4 had it, thunderbird now has it, but still not in mozilla. You want to email an image you have to resize it, save as it, click insert image and navigate to it. With others, ie outlook, just resize your image click copy and paste into message, no need to save it or anything. Sigh #24 Re: still no paste images into email, bug 4 yearsby itsayellow Thursday April 22nd, 2004 6:04 AM In thunderbird I usually just drag 'n' drop an image file into my email compose window. Seems to work fine ... I concur. This feature is sorely missed. Although there is a work-around, it's not very user friendly. This is an important usability issue that needs to be addressed. While it may seem like a small thing, it just the sort of non-feature that will turn off people trying out Mozilla, and prevent them from exploring further. > Promises of money to no avail you still can't paste a clipboard image into an email That may have something to do with the fact that there is pretty much no one working on the SeaMonkey mailnews UI at the moment. The person the bug is assigned to is CERTAINLY not working on SeaMonkey. And he _has_ implemented it in the browser he is working on (tbird). It may help to get the word out that there is a bounty on this bug; that may attract people who would never look at a mailnews bug normally to try and port the thunderbird code.... #68 Re: still no paste images into email, bug 4 yearsby Laurence Saturday April 24th, 2004 12:06 PM Is there anything that an enduser (not a programmer) can do, to get someone who can implement this feature, "the pasting of images directly from clipboard into the composition window," brought into the Mozilla Suite - and if not too late, especially into Mozilla 1.7 for it's official release? Laurence The release notes states the following: "also allows the user to review and retroactively open blocked windows via context (right-click) menu on the statusbar "blocked pop-up" icon." I am right clicking the popup blocker, but nothing happens when I do this. Am I doing something wrong? Do I need to set some hidden pref? I think this feature was removed again because it caused a security problem. Stefan It worked in 1.7 Alpha, then was gone in 1.7 Beta. I think it is bug 198846 http://bugzilla.mozilla.org/show_bug.cgi?id=198846 - Eric, http://www.InvisibleRobot.com/ I've just downloaded and installed 1.7rc1 and now Mozilla refuses to launch. More accurately, the splash screen appears and doesn't go away, the system tray icon (QuickLaunch) appears but no actual application windows will load, despite trying many different methods of bringing it up. More disconcerting though, after deciding to reinstall what I was previously using (1.7a) the same problem happens. It appears I can't run Mozilla at all any more! Anyone else having the same problem? Any suggestions? I've never encountered anything like this before... Ignore this earlier message. For some reason the Mozilla installer now needs to be run as administrator rather than power user... Actually, *don't* ignore this message. After installing as admin it seemed to launch fine, but now won't relaunch after installing some plugins. Same problem as before: sits on the splash screen forever... What plugins are that? Did you install the extension(s) into your profile directory? Btw, you chould check your install.log for any installation (or chrome registration) errors Thanks for that, I'll try reinstalling it and have a look at the logfile. FYI the process I followed was more or less this: 1. Installed 1.7rc1 (over 1.7a with plenty of extensions/the orbit 3+1 theme) 2. Rebooted 3. Removed and reinstalled 1.7rc1 4. Removed 1.7rc1 and reinstalled 1.7a 5. Removed 1.7a and installed 1.7rc1 as administrator (appeared to work) 6. Installed a number of extensions (pnhtoolbar, tabbrowser extensions etc.) - wherever possible installed globally (all users) 7. Restarted Mozilla to be greeted by non-loading again 8. Removed 1.7rc1 and started using Firefox, harumphing quite loud at the same time. I didn't mention before, but I'm using Windows XP Professional, as that may have some relevance. I have been watching what looks like a layout regression in 1.7. Was hoping it might be fixed by the RC, but not so. I have a test case at http://level11.com.au/mozbug/shell.htm. It works fine in 1.6, but the behaviour changes in 1.7 (tested on OS X and Win XP) - and in the process completely mucks up a significant app I have that works with moz. Any comments before I submit a bug report? Simon So what exactly is the bug? The presence of the horizontal scrollbar? I see the bug as the *change* in behaviour. 1.7 behaves completely different to that of 1.6. Specifically, the horizontal scrollbar appears, and the body border of the page in the iframe sits *infront* of the scrollbars. In 1.6, the horz scrollbar don't appear, and the border sits behind the scrollbars. The 1.6 behaviour is a result of a combination of body{overflow:auto} html,body {-moz-box-sizing: border-box} in the page in the iframe. If I comment out the body overflow:auto rule, then the behaviour in 1.6 and 1.7 is now identicle. So what is the correct behaviour given these CSS attributes? I guess only a CSS expert can say. But what I can say from observation - is that what behaved one way in 1.6 and 1.4.1, has now changed. This will be a problem for all designers that have come to depend on this behaviour - including me!
> I see the bug as the *change* in behaviour. 1.7 behaves completely different to that of 1.6. For overflow on root elements or bodies in HTML, yes. See bug 234851 and the discussion there. Basically, in 1.6 overflow:auto on the body made the body scrollable. So the border of the body was never visible. In 1.7, overflow:auto on the body affects the scrollbars of the associated "viewport" (frame or actual browser viewport). So the body is in fact scrolled, and you see the bottom border. This part of the changes is correct and likely to stay that way, I think. The new behavior is more like what CSS specifies (see http://www.w3.org/TR/CSS21/visufx.html#propdef-overflow and search for the "html UAs" line) and more like what IE does. The horizontal scrollbar is there because the <html> node overflows (due to its side borders). This is probably a bug under the circumstances; please file it, cc me and roc@ocallahan.org, ok? Thanks - I'll file a bug and cc you in. One minor point > Basically, in 1.6 overflow:auto on the body made the body scrollable. So the border of the body was never visible. I've changed the test case at http://level11.com.au/mozbug/shell.htm to make the borders on the iframe document clearer. I think this makes the problem much easier to spot (note these border are not iframe borders). I have two borders: yellow and red. The yellow is on the html element (which also has height set to 100%), the red is on the body element. With the html and body CSS rules, when scrolled (in 1.4,1.6) the document content scrolled, but these borders remain visible and sit on the edge of the viewport. The change in behaviour with 1.7 looks like the borders are now scrolling with the document, and the html height is now the height of the document, rather than the height of the viewport. So the behaviour has changed in 2 different areas, with the third effect of the horizontal scrollbar appearing ?? Ummm .. In any case, I'll put it in the bug report. Simon. > The change in behaviour with 1.7 looks like the borders are now scrolling with the document, and the html > height is now the height of the document, rather than the height of the viewport. Yes, exactly. Please keep the bug report focused on the horizontal scrollbar, ok? If you want, file a separate bug on the change in border behavior (I suspect that will end up being invalid, unlike the horizontal scrollbar thing). One last word :) I've just tested that the behaviour of 1.7 is also contrary to how IE6 behaves. Just point IE6 to my test case and have a look. So IE 6, moz 1.6 & moz 1.4.1 all behave the same way, and moz 1.7 blows all this outta the water! This must be considered a regression. Simon. > So IE 6, moz 1.6 & moz 1.4.1 all behave the same way On your particular testcase, yes. Not on others, though. We don't really want to copy all of IE's bugs with root elements (starting with the fact that the wrong element is the root in IE), though. -Boris Hi Boris, I can see your are doing good work here with Moz (and thanks), but I have to put my case forward. No - we don't want to copy IE's bugs, but we do want to create maximum product stability. This change could throw out compatibility between IE6 and Moz 1.6 and prior - on this particular layout issue. Is my test scenario really that unique? How many products will have their UI broken by this change? I can tell you this change in behaviour is going to cost me $$. I will have to revisit a number of DHTML business apps all with the same scenario as in my test case - which was distilled down from a UI we are currently doing, after I got a "Yo - check out what Moz 1.7 has done to us ....". And I will have to create moz specific styling. Virtually none of my corporate customers use moz/firefox - but I actively make sure anything my group turns out works the same in both IE and Moz. I want to keep them as open as possible to moving off of IE. But this sort of change makes it just a bit harder for me to do so. Simon. Yep - you're right (Boris, Sam). I created a bug http://bugzilla.mozilla.org/show_bug.cgi?id=241405 which has been jumped on pretty quickly. I now see the nuances to this CSS behaviour, and yes I do agree it makes no sense continuing a behaviour that is erronous! So yes - it does break my UIs, but thankfully the workaround is very simple - all I need to do is apply html {overflow:hidden} to my iframe documents and done! I've created a new test case at http://level11.com.au/mozfix/shell.htm if you are interested. Simon. I haven't looked at this in detail, but frankly the containing element / viewport behaviour was previously wrong in both IE and Mozilla by my reading, so maybe they've fixed it now. I remember taking part in a long mailing list thread about it once... Relying on dubious, probably incorrect CSS behaviour at the bleeding edge is usually a bad idea. (Even if it is annoying that this means there are some things you can't do.) To make matters worse, this area was rather unclearly defined in CSS2, I don't know whether they tidied it up in 2.1... Anyway, in my mind the summary of this area is that CSS is definitely a mess but Mozilla ought to make an effort to do what the spec says anyhow. Maybe they'll fix it in CSS3. (*not holding breath*) As for 1.7 rc1... looks ok to me. :) I haven't had any problems. Oh... except that of course not being able to use .mht files has made it completely unusable as a primary browser. Apparently. I seem to have muddled through for the last couple of years; on the one (1) occasion I wanted to make a .mht file I, er, loaded Internet Explorer... of course compared to the other 10,000 browser sessions for which Mozilla was preferable, this immediately made me select IE as my default browser, although the enormous number of advantages Mozilla has do still make it barely acceptable for fun browsing. --sam I've had a closer look at bug 241304, and maybe it is the cause of my issue? I can't test that this fix also cures my prob until I can grab a build with the 241304 fix applied. I've just grabbed the latest/, latest-trunk/ and latest-1.7/ mac builds and tested against the 'overflow test' document (listed in bugzilla), and 241304 still fails. Simon
What about bug <http://bugzilla.mozilla.org/show_bug.cgi?id=40873>? Is it ever going to be addressed?????????? Without it being fixed Mozilla remains second best, almost good enough, but not ready for prime time, fun to browse in but not a "default" browser. Please address this bug! Note that at least the newly coming message/rfc822 in thunderbird means it will be from now on very easy to open them. There's still a few bugs (attached images), but work is very active to fix them. > What about bug 40873? What about it? It is the bug you mention quite a few times already (if I'm not wrong). A bug that is not really a bug, but an enhancement request, a request for saving a complete page in one file instead of in a file plus folder. It affects nobody when "browsing" alone, it's just about saving. And it's not like Mozilla cannot save web pages, it's just that you want to have it saved in one file. I do not say your desire is wrong, but I have a hard time trying to understand how this ridiculously unimportant difference determines if a browser is ready for prime time or not. Do you also decide what car you buy by looking at if its manual is printed in color or black&white only? "Wow, that new Ferrari is a quite good car, but it's not ready for prime time yet: its manual is still not in color!" > Is it ever going to be addressed?????????? As soon as you create a patch. It's _very_ low priority as far as I can tell. > Without it being fixed Mozilla remains second best, almost good enough, but not ready for prime time Everyone (well, everyone who doesn't actually plan to do anything about it) always says that about their favorite bug. Saying it does nothing to make the bug more likely to get fixed; it just makes people laugh at you.... Well, I laugh at you in return as you obviously lack reason or logic. Mozilla is onot up to the capabilities of Internet Explorer which everyone loves to criticize. > as you obviously lack reason or logic I see. Note that I didn't say I was laughing at you; I just tried to help you by pointing out that your comments lent themselves to being perceived in a light unfavorable to you. I'm glad that I got such a mature response. > Mozilla is onot up to the capabilities of Internet Explorer It's far ahead of them. It runs on the computers I need it to run on, whereas IE does not (with the rare exception of IE5/Solaris, which is a rather bad browser if you've ever tried it). That makes all the difference to me. Well, I noticed that some images are missing in this homepage (it's a big shop in Spain) http://www.fnac.es it worked propperly in Mozilla <=1.7a (not in Mozilla 1.7b) and it works ok in Firefox 0.8. I also wanted to notice you that when you click in one product (the image or the link), you go to the product's detail homepage. And there you have a link to make the image bigger (in spanish "ampliar imagen"), and there is a "bug" that makes the window of a fixed size (it's resized according to the size of the image). I revised the script and it should work ok (well it uses the layers feature of Netscape 4), but it doesn't work on Mozilla (well in older versions it allowed you to resize the pop-up window... but I think it was 0.XX version, I mean that it shouldn't allow you to resize it). I wrote a message to the webmaster when they made a redesign of the site (there was a contest asking users about the redesign), but I had no reply. I really would like this feature to work on Mozilla, because I use this page very often, and what I do it's to copy the address of the image, open a new tab and paste the address of the image... well, it works, but it's not what a common user wants. > Well, I noticed that some images are missing in this homepage Umm... for me it looks identical to what IE displays. Have you used image blocking? Or are there any flash animations and there is no flash plugin in your new Mozilla installation? > there is a "bug" that makes the window of a fixed size 'window.open( [...] ,scrollbars=no,resizable=no,width=50,height=50")' - so it's just like they designed it > I revised the script and it should work ok (well it uses the layers feature of Netscape 4) Please read http://bugzilla.mozilla.org/show_bug.cgi?id=19390 - "layers" is not supported in Mozilla. That comment was added at 1999-11-19, so fnac are using a feature that has been known not to be supported for more than four years!! The even more sad thing is that the necessary change is sooo small: window.innerHeight = document.layers[0].document.images[0].height; should be window.innerHeight = document.images[0].height; (just like in the IE version) to work (height respectively). Either they simply change it (that breaks the perhaps 1% NS4 users, but helps the perhaps 10% Gecko users they have) or they improve their browser sniffing and add a third case for browsers having "Gecko" in their user-agent (which also would help Konqueror and Safari). Both solutions take less than one minute to implement, so if they do not do it, you can build up your own opinion about them... I might well file a Tech Evang bug about it... Hello, There are 2 issues I think we should look at for 1.7final. The first is that if you do a print preview of www.mozilla.org, then you will see the "IconMozilla.jpg" image is split in two! I added a testcase for this into bug 237939. (if we don't have time to fix the underlying bug, we should find a way to workaround it at www.mozilla.org by release time). Also, the print preview of any page with frames (and iframes) is really messed up. If the contents of the frame are more than one page, then the print preview displays only one page. Also, you can scroll the contents of the frame with your mouse wheel... in print preview! See bug 239795. I think this is a recent regression. Be forewarned that some people have reported crashes will trying to reproduce these things. "Hello, There are 2 issues I think we should look at for 1.7final. The first is that if you do a print preview of <http://www.mozilla.org>, then you will see the "IconMozilla.jpg" image is split in two!" This may not be an issue with the way print preview is coded. It may be a different issue. On the Mac the print driver handles the print preview and not Mozilla, and still the image "IconMozilla.jpg" is split in two. (BTW I amd using an Epson 740 printer driver.) the link to ftp.eu.mozilla.org uses http, not ftp. is this intentional? also: drwxr-xr-- 4 infoadmi infoadmi 1024 Apr 22 03:37 mozilla1.7rc1 it's currently impossible to use 130.206.1.5, one of the two eu mirrors. "the link to ftp.eu.mozilla.org uses http, not ftp. is this intentional?" Yeah, we usually link to the HTTP versions of FTP sites because it provides a more consistent experience (staying on the same protocol etc.). Alex To make filetype icons before I had to go through the registry every time I installed a new version of Mozilla and find Mozilla's filetype entries and delete the DefaultIcon keys so Windows would make its own filetype icons out of a blank page icon with the 16x16 Mozilla icon in the middle. So I don't want to sound ungrateful, but the new filetype icons look somehow 'wrong' compared to the other Windows 2000 icons and the bolder blue/orange square Mozilla application icons. They're in bin\chrome\icons\default. The following page displays the same in IE and in Mozilla 1.6. It appears "broken" in 1.7b and 1.7RC1. http://torontolindyhop.com/toe/ Perhaps someone can tell me whether the "new" layout is intentional or a bug. Please file a Bugzilla bug and explain what has changed and why you think the new layout is wrong. If you can reduce the page to the smallest HTML that illustrates the problem, that would be helpful too. http://www.theregister.co.uk/2004/04/22/opera_7_50_beta/ Opera is about to release version 7.5 of their browser on 3 platforms, could this cause Netscape to release Netscape 7.5, or don't they care enough any more (you'd probably need a marketing department for something like that)? you would probably need ANY kind of department. i don't think they have any left... this is so totally Gothic - netscape is dead, yet it keeps coming back; just like Count Dracula :) now if only we could find some Garlic to apply to ms-ie Mozilla 1.7 RC1 doesn't have double 3D border on the bottom of #content, just like Firefox for a while now, ewww. Putting this into userChrome.css fixes it for me: #content { border: 0px none !important; border-top: 1px solid threeddarkshadow !important; border-bottom: 2px solid !important; -moz-border-bottom-colors: white threedlightshadow !important; } http://kodu.neti.ee/~tar/tmp/mozilla/userChrome.css Before: http://kodu.neti.ee/~tar/tmp/mozilla/border1.png After: http://kodu.neti.ee/~tar/tmp/mozilla/border2.png And yeah, I think borders left & right of the content are useless, since I run the browser maximized 99% of the time Rightclick on a image and "Save Image As..." pops up a messagebox with the title of Download Error and body of hostname of the image URL after saving the image. ouch! ok, it looks for me as if it had actually saved a valid image before giving the "error" message (UNLIKE the right-click-save-as-bug #238943 in the mail/news reader part of the suite). but this is still scary - some of us save images constantly from the right-click-save-image in the browser... anyone know if this (NEW) bug with 1.7rc1 is in bugzilla yet? this is different than #238943, that was mail/news, this is broswer, also this one did NOT appear in 1.7beta (whereas the #238943 seemed to start with 1.7b) |