MozillaZine

Mozilla 1.7 RC 1 Released

Wednesday April 21st, 2004

Asa 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.


#1 Flash in Linux

by jedbro

Wednesday April 21st, 2004 8:43 PM

Reply to this message

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

#9 Re: Flash in Linux

by zero0w

Wednesday April 21st, 2004 10:09 PM

Reply to this message

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.…file=article&sid=8574>

#2 Firebird?

by dpol <dpol@swipnet.se>

Wednesday April 21st, 2004 8:43 PM

Reply to this message

Even mozillaZine gets the new name wrong... :-)

#4 Re: Firebird?

by kerz <jason@mozillazine.org>

Wednesday April 21st, 2004 8:52 PM

Reply to this message

Shhhhhh.

#53 Re: Re: Firebird?

by zookqvalem

Thursday April 22nd, 2004 6:59 PM

Reply to this message

:-)

#3 Wrong TB 1.0 --> 0.6

by jedbro

Wednesday April 21st, 2004 8:44 PM

Reply to this message

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.

#5 Re: Wrong TB 1.0 --> 0.6

by kerz <jason@mozillazine.org>

Wednesday April 21st, 2004 8:52 PM

Reply to this message

And shhhhhh to you too!

jason

#6 SVG

by Racer

Wednesday April 21st, 2004 9:17 PM

Reply to this message

"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.

#7 Re: SVG

by superfly <superflysuper@netscape.net>

Wednesday April 21st, 2004 9:32 PM

Reply to this message

Yes, please enable SVG!

Will it be turned on before the final?

#8 Re: Re: SVG

by asa <asa@mozilla.org>

Wednesday April 21st, 2004 9:47 PM

Reply to this message

"Will it be turned on before the final?"

In the official Mozilla release? Absolutely not!

--Asa

#10 Re: Re: Re: SVG

by zero0w

Wednesday April 21st, 2004 10:11 PM

Reply to this message

So, any plan or time frame when SVG will go into the main branch of Mozilla?

#11 Re: Re: Re: Re: SVG

by asa <asa@mozilla.org>

Wednesday April 21st, 2004 11:12 PM

Reply to this message

'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

#12 Re: Re: Re: Re: SVG

by pmsyyz

Wednesday April 21st, 2004 11:36 PM

Reply to this message

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>

#13 Release notes

by WalterK

Thursday April 22nd, 2004 1:06 AM

Reply to this message

Bug 237845 is fixed. Should it be removed from the Know Issues section of Release Notes?

#14 Re: Release notes

by WalterK

Thursday April 22nd, 2004 1:10 AM

Reply to this message

Actually, all bugs under New Issues in the Known Issues page are marked fixed.

#15 EML messages import/save ?

by moondog_x

Thursday April 22nd, 2004 1:28 AM

Reply to this message

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?

#16 [slighly offtopic] Gecko embedded in Alias Maya

by AlMalossi <AlMalossi@gmx.net>

Thursday April 22nd, 2004 3:20 AM

Reply to this message

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/…eatures/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/…w/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 <zxcvbnm114@dcemail.com>

Thursday April 22nd, 2004 3:38 AM

Reply to this message

<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 years

by itsayellow

Thursday April 22nd, 2004 6:04 AM

Reply to this message

In thunderbird I usually just drag 'n' drop an image file into my email compose window. Seems to work fine ...

#31 Re: still no paste images into email, bug 4 ye

by c960657

Thursday April 22nd, 2004 7:42 AM

Reply to this message

Thunderbird also supports the paste image function (on Windows, at least). It is only in Mozilla it is missing.

#29 Re: still no paste images into email, bug 4 years

by kquiggle <kquiggle@earthlink.net>

Thursday April 22nd, 2004 7:03 AM

Reply to this message

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.

#39 Re: still no paste images into email, bug 4 years

by bzbarsky

Thursday April 22nd, 2004 9:25 AM

Reply to this message

> 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....

#67 Re: Re: still no paste images into email, bug 4 ye

by RMo

Saturday April 24th, 2004 11:06 AM

Reply to this message

Just out of curiousity, is this XUL-and-its-friends code, i.e., that which can be fixed by editing a Mozilla installation ... or is it something that would require modification to the C++ and recompilation?

#68 Re: still no paste images into email, bug 4 years

by Laurence

Saturday April 24th, 2004 12:06 PM

Reply to this message

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

#18 Can't retrieve blocked popups

by kaideleeuw

Thursday April 22nd, 2004 4:07 AM

Reply to this message

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?

#20 Re: Can't retrieve blocked popups

by borggraefe

Thursday April 22nd, 2004 4:56 AM

Reply to this message

I think this feature was removed again because it caused a security problem.

Stefan

#21 Re: Re: Can't retrieve blocked popups

by kaideleeuw

Thursday April 22nd, 2004 5:02 AM

Reply to this message

it is very misleading to have that info in the release notes. I'll post this on Asa's blog.

#48 RE: Can't retrieve blocked popups

by ecarlson

Thursday April 22nd, 2004 5:46 PM

Reply to this message

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/>

#19 Mozilla 1.7rc1 doesn't launch...

by kapowaz

Thursday April 22nd, 2004 4:54 AM

Reply to this message

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...

#22 Re: Mozilla 1.7rc1 doesn't launch...

by kapowaz

Thursday April 22nd, 2004 5:15 AM

Reply to this message

Ignore this earlier message. For some reason the Mozilla installer now needs to be run as administrator rather than power user...

#25 Re: Re: Mozilla 1.7rc1 doesn't launch...

by kapowaz

Thursday April 22nd, 2004 6:28 AM

Reply to this message

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...

#28 Re: Re: Re: Mozilla 1.7rc1 doesn't launch...

by bugs4hj <bugs4hj@netscape.net>

Thursday April 22nd, 2004 6:48 AM

Reply to this message

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

#30 Re: Re: Re: Re: Mozilla 1.7rc1 doesn't launch...

by kapowaz

Thursday April 22nd, 2004 7:06 AM

Reply to this message

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.

#23 Layout Regression

by SimonG

Thursday April 22nd, 2004 5:41 AM

Reply to this message

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

#35 Re: Layout Regression

by corwin

Thursday April 22nd, 2004 8:50 AM

Reply to this message

I see the bug too, an unnecessary horizontal scrollbar appears.

#40 Re: Layout Regression

by bzbarsky

Thursday April 22nd, 2004 9:35 AM

Reply to this message

So what exactly is the bug? The presence of the horizontal scrollbar?

#42 Re: Re: Layout Regression

by bzbarsky

Thursday April 22nd, 2004 9:49 AM

Reply to this message

Note that if it's the scrollbar this is dependent on bug 241304

#43 Re: Re: Layout Regression

by bzbarsky

Thursday April 22nd, 2004 12:23 PM

Reply to this message

Or do you mean the change in what 100% height does on the body there?

#44 Re: Re: Layout Regression

by SimonG

Thursday April 22nd, 2004 3:31 PM

Reply to this message

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!

#50 Re: Re: Re: Layout Regression

by bzbarsky

Thursday April 22nd, 2004 5:57 PM

Reply to this message

> 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/CSS2…ufx.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?

#51 Re: Re: Re: Re: Layout Regression

by SimonG

Thursday April 22nd, 2004 6:28 PM

Reply to this message

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.

#56 Re: Re: Re: Re: Re: Layout Regression

by bzbarsky

Thursday April 22nd, 2004 7:56 PM

Reply to this message

> 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).

#52 Re: Re: Re: Re: Layout Regression

by SimonG

Thursday April 22nd, 2004 6:57 PM

Reply to this message

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.

#57 Re: Re: Re: Re: Re: Layout Regression

by bzbarsky

Thursday April 22nd, 2004 7:57 PM

Reply to this message

> 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

#58 Re: Re: Re: Re: Re: Re: Layout Regression

by SimonG

Thursday April 22nd, 2004 8:43 PM

Reply to this message

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.

#61 Re: Re: Re: Re: Re: Re: Re: Layout Regression

by bzbarsky

Thursday April 22nd, 2004 11:25 PM

Reply to this message

> How many products will have their UI broken by this change?

That's actually a very good question. ;)

Anyway, this discussion should probably move to the bug at this point so all the relevant information is there....

#66 Re: Re: Re: Re: Re: Re: Layout Regression

by SimonG

Friday April 23rd, 2004 6:37 PM

Reply to this message

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.

#63 Re: Re: Re: Re: Re: Layout Regression

by leafdigital

Friday April 23rd, 2004 5:12 AM

Reply to this message

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

#54 Re: Re: Re: Re: Layout Regression

by SimonG

Thursday April 22nd, 2004 7:13 PM

Reply to this message

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.

#47 Re: Re: Layout Regression

by SimonG

Thursday April 22nd, 2004 5:31 PM

Reply to this message

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

#26 Please fix this bug!

by ronin65

Thursday April 22nd, 2004 6:34 AM

Reply to this message

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!

#27 .mht support

by jmd

Thursday April 22nd, 2004 6:47 AM

Reply to this message

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.

#33 Re: Please fix this bug!

by durbacher

Thursday April 22nd, 2004 8:15 AM

Reply to this message

> 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!"

#38 Re: Please fix this bug!

by bzbarsky

Thursday April 22nd, 2004 9:22 AM

Reply to this message

> 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....

#59 How about this "bug"????

by ronin65

Thursday April 22nd, 2004 9:51 PM

Reply to this message

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.

#60 Re: How about this "bug"????

by bzbarsky

Thursday April 22nd, 2004 10:39 PM

Reply to this message

> 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.

#32 Some images are missing

by jaxel

Thursday April 22nd, 2004 8:07 AM

Reply to this message

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.

#34 Re: Some images are missing

by durbacher

Thursday April 22nd, 2004 8:43 AM

Reply to this message

> 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...

#37 Re: Re: Some images are missing

by durbacher

Thursday April 22nd, 2004 9:03 AM

Reply to this message

#36 Reply

by napolj2

Thursday April 22nd, 2004 9:01 AM

Reply to this message

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! 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 <http://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.

#55 Print Preview n MacOS X

by pkb351 <pbergsagel@shaw.ca>

Thursday April 22nd, 2004 7:48 PM

Reply to this message

"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.)

#41 eu mirror

by winnetou

Thursday April 22nd, 2004 9:45 AM

Reply to this message

the link to <ftp://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.

#62 Re: eu mirror

by AlexBishop <alex@mozillazine.org>

Friday April 23rd, 2004 12:31 AM

Reply to this message

"the link to <ftp://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

#45 New set of icons for files associated with Mozilla

by dan123

Thursday April 22nd, 2004 3:50 PM

Reply to this message

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.

#46 Page display layout broken??

by soulek

Thursday April 22nd, 2004 4:07 PM

Reply to this message

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.

#64 Re: Argh...2

by roc <roc+moz@cs.cmu.edu>

Friday April 23rd, 2004 12:09 PM

Reply to this message

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.

#49 Opera 7.5

by thelem

Thursday April 22nd, 2004 5:56 PM

Reply to this message

<http://www.theregister.co…04/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)?

#71 Re: Opera 7.5

by roseman

Monday April 26th, 2004 11:19 AM

Reply to this message

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

#65 #content border-bottom

by Tar

Friday April 23rd, 2004 4:36 PM

Reply to this message

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/…mp/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

#69 image save bug

by Tar

Sunday April 25th, 2004 12:32 PM

Reply to this message

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.

#70 Re: image save bug

by roseman

Monday April 26th, 2004 11:16 AM

Reply to this message

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)