Thunderbird 3.0b3 builds available for testing
Thunderbird, Seamonkey, Calendar users ... you can help. Build1 for Thunderbird 3.0b3 is available at http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/3.0b3-candidates/build1/. We need as many people as possible to use them and report issue they find in those builds. When raising bugs in bugzilla while using these builds please mark them blocking of bug https://bugzilla.mozilla.org/show_bug.cgi?id=489128. Areas that need a good look : Spotlight search Integration os OS X Vista Search integration on Windows Pop usage on all platforms. Ludovic -- Ludovic Hirlimann MozillaMessaging QA lead http://www.spreadthunderbird.com/aff/79/2 ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Rendering problem in Firefox v2.0.0.20 and SeaMonkey v1.1.17.
On 7/15/2009 9:59 PM, Ant wrote: On 7/15/2009 8:38 AM PT, David E. Ross typed: I noticed lately Gizmodo's Web pages are rendering slowly and hogging Web browser's CPU and memory badly. Example: http://gizmodo.com/5313690/why-you-cant-complain-about-the-price-of-todays-gadgets Is anyone else having this problem? If so, then what's going on? Thank you in advance. :) on FF 1.5.0.9 / XP-SP2 that URL is a crapper... there is a script running that refuses to be killed, so I closed FF, disabled JavaScript and re-opened the URL it works properly that way for me. Try disabling JS, see what happens your end! reg I've seen Web pages with scripts that, when rendering of the page is done, a script then downloads additional scripts from a server. Sometimes it seems that one of the addtional scripts then downloads even more scripts. Since I have a dial-up Internet connection, this really slows things down. The Web site for the Vanguard Group (mutual funds) is one such site. I generally disable JavaScript when viewing pages at that site. However, I must enable JavaScript for certain pages to complete transactions or view account statements. Did you ever e-mail the Web team over there? If so, then any luck? :( There is also a problem with viewing parts of the Vanguard site with SeaMonkey, caused by sniffing for Firefox and not Gecko. See bug #417955 at https://bugzilla.mozilla.org/show_bug.cgi?id=417955. I sent E-mail to the Web team, I called them on the phone, and I sent a postal letter to the CEO. They claim that the security of their Web site requires that they test the site for any browser they allow to view it. (After all, Vanguard is one of the two largest mutual fund groups in the U.S.) They tested the site for Firefox but not for SeaMonkey. They don't agree that Gecko is Gecko. As for the delays caused by the use of scripts that download more scripts, their response was that I should use broadband service instead of dial-up. As for the sniffing for Firefox, I ran into the same problem with my bank and my credit union. I solved the problem by creating a special SeaMonkey profile where I am permanently spoofing Firefox. (The UA string ends with SeaMonkey/1.1.17 NOT Firefox/2.0.0.20.) To make these sites work, I also had to set my preferences to accept all cookies and all popups. I am careful not to browse any other sites from that profile. -- David E. Ross http://www.rossde.com/ Go to Mozdev at http://www.mozdev.org/ for quick access to extensions for Firefox, Thunderbird, SeaMonkey, and other Mozilla-related applications. You can access Mozdev much more quickly than you can Mozilla Add-Ons. ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Rendering problem in Firefox v2.0.0.20 and SeaMonkey v1.1.17.
Date: 7/16/2009 12:21 PM, Author: David E. Ross Wrote: On 7/15/2009 9:59 PM, Ant wrote: On 7/15/2009 8:38 AM PT, David E. Ross typed: I noticed lately Gizmodo's Web pages are rendering slowly and hogging Web browser's CPU and memory badly. Example: http://gizmodo.com/5313690/why-you-cant-complain-about-the-price-of-todays-gadgets Is anyone else having this problem? If so, then what's going on? Thank you in advance. :) on FF 1.5.0.9 / XP-SP2 that URL is a crapper... there is a script running that refuses to be killed, so I closed FF, disabled JavaScript and re-opened the URL it works properly that way for me. Try disabling JS, see what happens your end! reg I've seen Web pages with scripts that, when rendering of the page is done, a script then downloads additional scripts from a server. Sometimes it seems that one of the addtional scripts then downloads even more scripts. Since I have a dial-up Internet connection, this really slows things down. The Web site for the Vanguard Group (mutual funds) is one such site. I generally disable JavaScript when viewing pages at that site. However, I must enable JavaScript for certain pages to complete transactions or view account statements. Did you ever e-mail the Web team over there? If so, then any luck? :( There is also a problem with viewing parts of the Vanguard site with SeaMonkey, caused by sniffing for Firefox and not Gecko. See bug #417955 at https://bugzilla.mozilla.org/show_bug.cgi?id=417955. I sent E-mail to the Web team, I called them on the phone, and I sent a postal letter to the CEO. They claim that the security of their Web site requires that they test the site for any browser they allow to view it. (After all, Vanguard is one of the two largest mutual fund groups in the U.S.) They tested the site for Firefox but not for SeaMonkey. They don't agree that Gecko is Gecko. As for the delays caused by the use of scripts that download more scripts, their response was that I should use broadband service instead of dial-up. As for the sniffing for Firefox, I ran into the same problem with my bank and my credit union. I solved the problem by creating a special SeaMonkey profile where I am permanently spoofing Firefox. (The UA string ends with SeaMonkey/1.1.17 NOT Firefox/2.0.0.20.) To make these sites work, I also had to set my preferences to accept all cookies and all popups. I am careful not to browse any other sites from that profile. Someone should explain to the morons that browser sniffing has absolutely *NO* security benefits. Opera has UA spoofing built in, all Mozilla products have UA switcher extensions available but it can be without one, and even IE8 has a UA picker that can spoof as Firefox, Netscape or even a cell phone. Sniffing for the UA string is like saying that if you are clever enough to write Employee on a 3x5 card and wear it on your lapel, you are free to enter and leave the safe it will :-( My company's website requires IE5.5+ or Netscape 7.1+. I set up a profile to spoof as Netscape 7.2 and happily access the site with Minefield 3.6a :-) -- G. R. Woodring ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Rendering problem in Firefox v2.0.0.20 and SeaMonkey v1.1.17.
G. R. Woodring wrote: Date: 7/16/2009 12:21 PM, Author: David E. Ross Wrote: On 7/15/2009 9:59 PM, Ant wrote: On 7/15/2009 8:38 AM PT, David E. Ross typed: I noticed lately Gizmodo's Web pages are rendering slowly and hogging Web browser's CPU and memory badly. Example: http://gizmodo.com/5313690/why-you-cant-complain-about-the-price-of-todays-gadgets Is anyone else having this problem? If so, then what's going on? Thank you in advance. :) on FF 1.5.0.9 / XP-SP2 that URL is a crapper... there is a script running that refuses to be killed, so I closed FF, disabled JavaScript and re-opened the URL it works properly that way for me. Try disabling JS, see what happens your end! reg I've seen Web pages with scripts that, when rendering of the page is done, a script then downloads additional scripts from a server. Sometimes it seems that one of the addtional scripts then downloads even more scripts. Since I have a dial-up Internet connection, this really slows things down. The Web site for the Vanguard Group (mutual funds) is one such site. I generally disable JavaScript when viewing pages at that site. However, I must enable JavaScript for certain pages to complete transactions or view account statements. Did you ever e-mail the Web team over there? If so, then any luck? :( There is also a problem with viewing parts of the Vanguard site with SeaMonkey, caused by sniffing for Firefox and not Gecko. See bug #417955 at https://bugzilla.mozilla.org/show_bug.cgi?id=417955. I sent E-mail to the Web team, I called them on the phone, and I sent a postal letter to the CEO. They claim that the security of their Web site requires that they test the site for any browser they allow to view it. (After all, Vanguard is one of the two largest mutual fund groups in the U.S.) They tested the site for Firefox but not for SeaMonkey. They don't agree that Gecko is Gecko. As for the delays caused by the use of scripts that download more scripts, their response was that I should use broadband service instead of dial-up. As for the sniffing for Firefox, I ran into the same problem with my bank and my credit union. I solved the problem by creating a special SeaMonkey profile where I am permanently spoofing Firefox. (The UA string ends with SeaMonkey/1.1.17 NOT Firefox/2.0.0.20.) To make these sites work, I also had to set my preferences to accept all cookies and all popups. I am careful not to browse any other sites from that profile. Someone should explain to the morons that browser sniffing has absolutely *NO* security benefits. Opera has UA spoofing built in, all Mozilla products have UA switcher extensions available but it can be without one, and even IE8 has a UA picker that can spoof as Firefox, Netscape or even a cell phone. Sniffing for the UA string is like saying that if you are clever enough to write Employee on a 3x5 card and wear it on your lapel, you are free to enter and leave the safe it will :-( My company's website requires IE5.5+ or Netscape 7.1+. I set up a profile to spoof as Netscape 7.2 and happily access the site with Minefield 3.6a :-) Then there are the sites, run by a large software/OS company, that sniff to determine if you are using a rival browser and make sure the display is just enough 'off' to make like unpleasant. That kind of thing is just petty, and juvenile. ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Rendering problem in Firefox v2.0.0.20 and SeaMonkey v1.1.17.
David E. Ross wrote: On 7/15/2009 9:59 PM, Ant wrote: On 7/15/2009 8:38 AM PT, David E. Ross typed: I noticed lately Gizmodo's Web pages are rendering slowly and hogging Web browser's CPU and memory badly. Example: http://gizmodo.com/5313690/why-you-cant-complain-about-the-price-of-todays-gadgets Is anyone else having this problem? If so, then what's going on? Thank you in advance. :) on FF 1.5.0.9 / XP-SP2 that URL is a crapper... there is a script running that refuses to be killed, so I closed FF, disabled JavaScript and re-opened the URL it works properly that way for me. Try disabling JS, see what happens your end! reg I've seen Web pages with scripts that, when rendering of the page is done, a script then downloads additional scripts from a server. Sometimes it seems that one of the addtional scripts then downloads even more scripts. Since I have a dial-up Internet connection, this really slows things down. The Web site for the Vanguard Group (mutual funds) is one such site. I generally disable JavaScript when viewing pages at that site. However, I must enable JavaScript for certain pages to complete transactions or view account statements. Did you ever e-mail the Web team over there? If so, then any luck? :( There is also a problem with viewing parts of the Vanguard site with SeaMonkey, caused by sniffing for Firefox and not Gecko. See bug #417955 athttps://bugzilla.mozilla.org/show_bug.cgi?id=417955. I sent E-mail to the Web team, I called them on the phone, and I sent a postal letter to the CEO. They claim that the security of their Web site requires that they test the site for any browser they allow to view it. (After all, Vanguard is one of the two largest mutual fund groups in the U.S.) They tested the site for Firefox but not for SeaMonkey. They don't agree that Gecko is Gecko. As for the delays caused by the use of scripts that download more scripts, their response was that I should use broadband service instead of dial-up. As for the sniffing for Firefox, I ran into the same problem with my bank and my credit union. I solved the problem by creating a special SeaMonkey profile where I am permanently spoofing Firefox. (The UA string ends with SeaMonkey/1.1.17 NOT Firefox/2.0.0.20.) To make these sites work, I also had to set my preferences to accept all cookies and all popups. I am careful not to browse any other sites from that profile. David, I think it may be a little-more complicated than simply sniffing the Firefox vs SeaMonkey UA. I don't have a Vanguard account, so that may be a factor for me... I don't spoof-UA ever, but using the nightly-Linux-64bit build over broadband ~ Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2a1pre) Gecko/20090716 Lightning/1.0pre SeaMonkey/2.1a1pre ID:20090716013332 on your UA/Flash test-URL at https://personal.vanguard.com/us/VanguardViewsArticlePublic?ArticleJSP=/freshness/News_and_Views/news_ALL_mmyields_01262009_ALL.jspsrc=NMCreturnLink=/freshness/News_and_Views/news_ALL_mmyields_01262009_ALL.jsp https://personal.vanguard.com/us/VanguardViewsArticlePublic?ArticleJSP=/freshness/News_and_Views/news_ALL_mmyields_01262009_ALL.jspsrc=NMCreturnLink=/freshness/News_and_Views/news_ALL_mmyields_01262009_ALL.jsp I got this :- http://www.flickr.com/photos/22198...@n03/3727717220/sizes/l/ Which I think, renders the page OK? What do you think? Barry. ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Rendering problem in Firefox v2.0.0.20 and SeaMonkey v1.1.17.
Barry Edwin Gilmour wrote: David E. Ross wrote: On 7/15/2009 9:59 PM, Ant wrote: On 7/15/2009 8:38 AM PT, David E. Ross typed: I noticed lately Gizmodo's Web pages are rendering slowly and hogging Web browser's CPU and memory badly. Example: http://gizmodo.com/5313690/why-you-cant-complain-about-the-price-of-todays-gadgets Is anyone else having this problem? If so, then what's going on? Thank you in advance. :) on FF 1.5.0.9 / XP-SP2 that URL is a crapper... there is a script running that refuses to be killed, so I closed FF, disabled JavaScript and re-opened the URL it works properly that way for me. Try disabling JS, see what happens your end! reg I've seen Web pages with scripts that, when rendering of the page is done, a script then downloads additional scripts from a server. Sometimes it seems that one of the addtional scripts then downloads even more scripts. Since I have a dial-up Internet connection, this really slows things down. The Web site for the Vanguard Group (mutual funds) is one such site. I generally disable JavaScript when viewing pages at that site. However, I must enable JavaScript for certain pages to complete transactions or view account statements. Did you ever e-mail the Web team over there? If so, then any luck? :( There is also a problem with viewing parts of the Vanguard site with SeaMonkey, caused by sniffing for Firefox and not Gecko. See bug #417955 athttps://bugzilla.mozilla.org/show_bug.cgi?id=417955. I sent E-mail to the Web team, I called them on the phone, and I sent a postal letter to the CEO. They claim that the security of their Web site requires that they test the site for any browser they allow to view it. (After all, Vanguard is one of the two largest mutual fund groups in the U.S.) They tested the site for Firefox but not for SeaMonkey. They don't agree that Gecko is Gecko. As for the delays caused by the use of scripts that download more scripts, their response was that I should use broadband service instead of dial-up. As for the sniffing for Firefox, I ran into the same problem with my bank and my credit union. I solved the problem by creating a special SeaMonkey profile where I am permanently spoofing Firefox. (The UA string ends with SeaMonkey/1.1.17 NOT Firefox/2.0.0.20.) To make these sites work, I also had to set my preferences to accept all cookies and all popups. I am careful not to browse any other sites from that profile. David, I think it may be a little-more complicated than simply sniffing the Firefox vs SeaMonkey UA. I don't have a Vanguard account, so that may be a factor for me... I don't spoof-UA ever, but using the nightly-Linux-64bit build over broadband ~ Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2a1pre) Gecko/20090716 Lightning/1.0pre SeaMonkey/2.1a1pre ID:20090716013332 on your UA/Flash test-URL at https://personal.vanguard.com/us/VanguardViewsArticlePublic?ArticleJSP=/freshness/News_and_Views/news_ALL_mmyields_01262009_ALL.jspsrc=NMCreturnLink=/freshness/News_and_Views/news_ALL_mmyields_01262009_ALL.jsp I got this :- http://www.flickr.com/photos/22198...@n03/3727717220/sizes/l/ Which I think, renders the page OK? What do you think? Barry. A possible-clue maybe that at the time you made that test, you were using 32bit Flash 10.0.12.36 (10.0 r12), whereas I notice I am now using 64bit Flash-10.0.22.87-2 edition, which is more-stable than that older flash which had many-rendering-problems, including fullscreen-crashes on 32bit-Linux. ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Some web pages not showing up right
Paul Hartman wrote: On Wed, Jul 15, 2009 at 11:19 AM, Paul B. Gallagher pau...@pbgdashtranslations.com wrote: Martin Feitag wrote: I've never seen a major website which causes problems for Seamonkey 1.1.x _without_ having fatal errors. Well, I guess there's a philosophical question here -- are we attorneys or are we programmers? The sticklers are right, of course, to say that these pages are chock-full of errors. But end users don't care if you're right, they want to see the content. So if they have to choose between a program that displays a reasonable facsimile of the author's intent and one that displays hash, they'll choose the program that shows the content. So would you rather be right, or would you rather be popular? In an ideal world, I'd like to see SeaMonkey show a disclaimer (the way it does in the mail app when it blocks remote content) saying something along the lines that this page contains fatal errors in its coding, but we've done the best we could to divine what the designer wanted, and we're showing you that but we might've guessed wrong. ;-) Yes, the problem is that the author of the page in question specifically declared his page as being XHTML 1.0 Transitional and then violated all the rules. He could have just as easily left off the doctype and left it up to the browser to interpret the page in quirks mode or however it saw fit. By displaying buggy pages correctly, incompetence and laziness is rewarded. In fact a proper XHTML page served with application/xhtml+xml mime type will not display at all if there is a single error in the markup. Who are you punishing? The end user, dissatisfied with being unable to view a page, will often switch to the other browser, rewarding the incompetence and punishing the stickler. I know that's what I do when I really need the content. The only time I give up and move on is when I don't care about the content. For example, in my work for my political party, I monitor home sales and deaths in my county, the former so we can send someone to welcome new homeowners and strike the move-outs off our lists, and the latter so we can strike decedents and not disturb their grieving families. The county websites work only with Internet Exploiter, so I have to choose between doing this valuable work and using the right browser (which BTW is my default and my favorite). I choose to do the work. http://rodviewer.montcopa.org/countyweb/login.jsp?countyname=Montgomery http://propertyrecords.montcopa.org/Search/SalesSearch.aspx?mode=sales I would rather be right than popular :) Be careful what you wish for. ;-) -- War doesn't determine who's right, just who's left. -- Paul B. Gallagher ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Rendering problem in Firefox v2.0.0.20 and SeaMonkey v1.1.17.
On 7/16/2009 1:28 PM, Barry Edwin Gilmour wrote: David E. Ross wrote: On 7/15/2009 9:59 PM, Ant wrote: On 7/15/2009 8:38 AM PT, David E. Ross typed: I noticed lately Gizmodo's Web pages are rendering slowly and hogging Web browser's CPU and memory badly. Example: http://gizmodo.com/5313690/why-you-cant-complain-about-the-price-of-todays-gadgets Is anyone else having this problem? If so, then what's going on? Thank you in advance. :) on FF 1.5.0.9 / XP-SP2 that URL is a crapper... there is a script running that refuses to be killed, so I closed FF, disabled JavaScript and re-opened the URL it works properly that way for me. Try disabling JS, see what happens your end! reg I've seen Web pages with scripts that, when rendering of the page is done, a script then downloads additional scripts from a server. Sometimes it seems that one of the addtional scripts then downloads even more scripts. Since I have a dial-up Internet connection, this really slows things down. The Web site for the Vanguard Group (mutual funds) is one such site. I generally disable JavaScript when viewing pages at that site. However, I must enable JavaScript for certain pages to complete transactions or view account statements. Did you ever e-mail the Web team over there? If so, then any luck? :( There is also a problem with viewing parts of the Vanguard site with SeaMonkey, caused by sniffing for Firefox and not Gecko. See bug #417955 athttps://bugzilla.mozilla.org/show_bug.cgi?id=417955. I sent E-mail to the Web team, I called them on the phone, and I sent a postal letter to the CEO. They claim that the security of their Web site requires that they test the site for any browser they allow to view it. (After all, Vanguard is one of the two largest mutual fund groups in the U.S.) They tested the site for Firefox but not for SeaMonkey. They don't agree that Gecko is Gecko. As for the delays caused by the use of scripts that download more scripts, their response was that I should use broadband service instead of dial-up. As for the sniffing for Firefox, I ran into the same problem with my bank and my credit union. I solved the problem by creating a special SeaMonkey profile where I am permanently spoofing Firefox. (The UA string ends with SeaMonkey/1.1.17 NOT Firefox/2.0.0.20.) To make these sites work, I also had to set my preferences to accept all cookies and all popups. I am careful not to browse any other sites from that profile. David, I think it may be a little-more complicated than simply sniffing the Firefox vs SeaMonkey UA. I don't have a Vanguard account, so that may be a factor for me... I don't spoof-UA ever, but using the nightly-Linux-64bit build over broadband ~ Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2a1pre) Gecko/20090716 Lightning/1.0pre SeaMonkey/2.1a1pre ID:20090716013332 on your UA/Flash test-URL at https://personal.vanguard.com/us/VanguardViewsArticlePublic?ArticleJSP=/freshness/News_and_Views/news_ALL_mmyields_01262009_ALL.jspsrc=NMCreturnLink=/freshness/News_and_Views/news_ALL_mmyields_01262009_ALL.jsp https://personal.vanguard.com/us/VanguardViewsArticlePublic?ArticleJSP=/freshness/News_and_Views/news_ALL_mmyields_01262009_ALL.jspsrc=NMCreturnLink=/freshness/News_and_Views/news_ALL_mmyields_01262009_ALL.jsp I got this :- http://www.flickr.com/photos/22198...@n03/3727717220/sizes/l/ Which I think, renders the page OK? What do you think? Barry. Sniffing problems do not afflict all Vanguard pages. They definitely afflict getting my IRS 1099 forms (dividends, interest, etc). Of course, this is where security is important, protecting my personal financial information. On the other hand, the News pages are severely affected by scripts downloading additional scripts. I can't view the pages unless I allow this to happen. It's damned annoying to be reading a news item and suddenly have the whole page blank out and then reload because a script downloaded another script that finally started executing, especially if none of the scripts contribute anything to the content of the page I'm reading (other than JavaScript links to other pages). -- David E. Ross http://www.rossde.com/ Go to Mozdev at http://www.mozdev.org/ for quick access to extensions for Firefox, Thunderbird, SeaMonkey, and other Mozilla-related applications. You can access Mozdev much more quickly than you can Mozilla Add-Ons. ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Rendering problem in Firefox v2.0.0.20 and SeaMonkey v1.1.17.
On 7/16/2009 1:53 PM, Barry Edwin Gilmour wrote: Barry Edwin Gilmour wrote: David E. Ross wrote: On 7/15/2009 9:59 PM, Ant wrote: On 7/15/2009 8:38 AM PT, David E. Ross typed: I noticed lately Gizmodo's Web pages are rendering slowly and hogging Web browser's CPU and memory badly. Example: http://gizmodo.com/5313690/why-you-cant-complain-about-the-price-of-todays-gadgets Is anyone else having this problem? If so, then what's going on? Thank you in advance. :) on FF 1.5.0.9 / XP-SP2 that URL is a crapper... there is a script running that refuses to be killed, so I closed FF, disabled JavaScript and re-opened the URL it works properly that way for me. Try disabling JS, see what happens your end! reg I've seen Web pages with scripts that, when rendering of the page is done, a script then downloads additional scripts from a server. Sometimes it seems that one of the addtional scripts then downloads even more scripts. Since I have a dial-up Internet connection, this really slows things down. The Web site for the Vanguard Group (mutual funds) is one such site. I generally disable JavaScript when viewing pages at that site. However, I must enable JavaScript for certain pages to complete transactions or view account statements. Did you ever e-mail the Web team over there? If so, then any luck? :( There is also a problem with viewing parts of the Vanguard site with SeaMonkey, caused by sniffing for Firefox and not Gecko. See bug #417955 athttps://bugzilla.mozilla.org/show_bug.cgi?id=417955. I sent E-mail to the Web team, I called them on the phone, and I sent a postal letter to the CEO. They claim that the security of their Web site requires that they test the site for any browser they allow to view it. (After all, Vanguard is one of the two largest mutual fund groups in the U.S.) They tested the site for Firefox but not for SeaMonkey. They don't agree that Gecko is Gecko. As for the delays caused by the use of scripts that download more scripts, their response was that I should use broadband service instead of dial-up. As for the sniffing for Firefox, I ran into the same problem with my bank and my credit union. I solved the problem by creating a special SeaMonkey profile where I am permanently spoofing Firefox. (The UA string ends with SeaMonkey/1.1.17 NOT Firefox/2.0.0.20.) To make these sites work, I also had to set my preferences to accept all cookies and all popups. I am careful not to browse any other sites from that profile. David, I think it may be a little-more complicated than simply sniffing the Firefox vs SeaMonkey UA. I don't have a Vanguard account, so that may be a factor for me... I don't spoof-UA ever, but using the nightly-Linux-64bit build over broadband ~ Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2a1pre) Gecko/20090716 Lightning/1.0pre SeaMonkey/2.1a1pre ID:20090716013332 on your UA/Flash test-URL at https://personal.vanguard.com/us/VanguardViewsArticlePublic?ArticleJSP=/freshness/News_and_Views/news_ALL_mmyields_01262009_ALL.jspsrc=NMCreturnLink=/freshness/News_and_Views/news_ALL_mmyields_01262009_ALL.jsp I got this :- http://www.flickr.com/photos/22198...@n03/3727717220/sizes/l/ Which I think, renders the page OK? What do you think? Barry. A possible-clue maybe that at the time you made that test, you were using 32bit Flash 10.0.12.36 (10.0 r12), whereas I notice I am now using 64bit Flash-10.0.22.87-2 edition, which is more-stable than that older flash which had many-rendering-problems, including fullscreen-crashes on 32bit-Linux. Actually, I block Flash by using the FlashBlock extension. I do not seem to miss any significant content in the Vanguard site by blocking Flash. In general, when a Web page uses Flash, it's merely for a whiz-bang effect and contributes nothing to content. This is true for most Web sites, not just Vanguard. Yes, there are a few sites that require Flash for navigating; for some sites, the home page is merely one large Flash presentation. I consider that to be an abominable practice. (For cases when I cannot avoid viewing a Flash presentation, I'm currently using Flash 10.0.22.87. I'm running WindowsXP SP2.) -- David E. Ross http://www.rossde.com/ Go to Mozdev at http://www.mozdev.org/ for quick access to extensions for Firefox, Thunderbird, SeaMonkey, and other Mozilla-related applications. You can access Mozdev much more quickly than you can Mozilla Add-Ons. ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Some web pages not showing up right
On 7/16/2009 2:34 PM, Paul B. Gallagher wrote: Paul Hartman wrote: On Wed, Jul 15, 2009 at 11:19 AM, Paul B. Gallagher pau...@pbgdashtranslations.com wrote: Martin Feitag wrote: I've never seen a major website which causes problems for Seamonkey 1.1.x _without_ having fatal errors. Well, I guess there's a philosophical question here -- are we attorneys or are we programmers? The sticklers are right, of course, to say that these pages are chock-full of errors. But end users don't care if you're right, they want to see the content. So if they have to choose between a program that displays a reasonable facsimile of the author's intent and one that displays hash, they'll choose the program that shows the content. So would you rather be right, or would you rather be popular? In an ideal world, I'd like to see SeaMonkey show a disclaimer (the way it does in the mail app when it blocks remote content) saying something along the lines that this page contains fatal errors in its coding, but we've done the best we could to divine what the designer wanted, and we're showing you that but we might've guessed wrong. ;-) Yes, the problem is that the author of the page in question specifically declared his page as being XHTML 1.0 Transitional and then violated all the rules. He could have just as easily left off the doctype and left it up to the browser to interpret the page in quirks mode or however it saw fit. By displaying buggy pages correctly, incompetence and laziness is rewarded. In fact a proper XHTML page served with application/xhtml+xml mime type will not display at all if there is a single error in the markup. Who are you punishing? The end user, dissatisfied with being unable to view a page, will often switch to the other browser, rewarding the incompetence and punishing the stickler. I know that's what I do when I really need the content. The only time I give up and move on is when I don't care about the content. For example, in my work for my political party, I monitor home sales and deaths in my county, the former so we can send someone to welcome new homeowners and strike the move-outs off our lists, and the latter so we can strike decedents and not disturb their grieving families. The county websites work only with Internet Exploiter, so I have to choose between doing this valuable work and using the right browser (which BTW is my default and my favorite). I choose to do the work. http://rodviewer.montcopa.org/countyweb/login.jsp?countyname=Montgomery http://propertyrecords.montcopa.org/Search/SalesSearch.aspx?mode=sales I would rather be right than popular :) Be careful what you wish for. ;-) The original post in this thread cited a Web page for a California state agency. California law requires state Web pages be accessible to the handicapped. In California, counties are considered agents of the state (unlike cities, which are governments distinct from the state). Thus, the law might also apply to counties. A page that can be viewed only with IE might violate that law as it is unlikely it can be rendered properly by an audio browser. -- David E. Ross http://www.rossde.com/ Go to Mozdev at http://www.mozdev.org/ for quick access to extensions for Firefox, Thunderbird, SeaMonkey, and other Mozilla-related applications. You can access Mozdev much more quickly than you can Mozilla Add-Ons. ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Some web pages not showing up right
On 07/16/2009 05:48 PM, David E. Ross wrote: On 7/16/2009 2:34 PM, Paul B. Gallagher wrote: Paul Hartman wrote: On Wed, Jul 15, 2009 at 11:19 AM, Paul B. Gallagher ... http://rodviewer.montcopa.org/countyweb/login.jsp?countyname=Montgomery http://propertyrecords.montcopa.org/Search/SalesSearch.aspx?mode=sales I would rather be right than popular :) Be careful what you wish for. ;-) The original post in this thread cited a Web page for a California state agency. California law requires state Web pages be accessible to the handicapped. In California, counties are considered agents of the state (unlike cities, which are governments distinct from the state). Thus, the law might also apply to counties. A page that can be viewed only with IE might violate that law as it is unlikely it can be rendered properly by an audio browser. The page can be viewed with multiple browsers (as I've previously mentioned). Further it can also be easily viewed even with SM 1.1.17 if you use View|Use Style|None. There has been no mention of an 'audio browser' in reference to the site or the subject: Some web pages not showing up right, so I'd recommend trying the site using an audio browser to test it for accessability issues then bring that up to the State of California, and a *new thread* if you wish. In that pursuit, this might be of interest/help: http://www.reportingtransparency.ca.gov/accessibility.html ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
