Re: SM 2.9.1 color scheme
Interviewed by CNN on 17/05/2012 14:59, W3BNR told the world: I accomplished two things this last week: 1. New Computer - now running Windows 7 2. Installed SM 2.9.1 on new computer Using the SM Default Theme when I 'hover' over an item, either the icon for a drop-down menu or an item in the drop-down menu the text changes to white and the background is the same as the existing background except lighter.. Very hard to read what is selected. If I switch to SM Modern Theme this hovering action shows black text on a light blue background. Easy to read. Also on my Linux Mint machine running SM 2.9.1 Default theme the background is black and the text is white. Also easy to read. This would seem be be a change in SM 2.9.1 not Win 7. Anyone else seeing this? OK. First of all, let me make clear that I'm also using SM 2.9.1 on Windows 7 X64 SP1. For the purposes of this thing, I disabled the Personas mini-theme I was using and reverted to plain Seamonkey Default Theme. If Windows 7 is using the Windows Classic theme (the one that looks rather like Windows 2000, or perhaps Win98), the toolbars/menubars of SM take beige-ish shade, one very very slightly warmer (that is, beiger as opposed as greyer) to my eyes than the Windows Explorer toolbars. In this legacy mode, menus keep the same color (black on gray), except when you are hovering the mouse over a line of an opened menu -- then that line is displayed as white text over dark blue background. Hovering the mouse over a button or a *closed* menu only highlights it with an outset border, making it look like a button to be pressed. In the case of the toolbar icons, there are slightly different icons for the normal, hover and pressed states. That's all consistent -- although not quite identical -- with the Windows theme. On Windows 7 Basic or Aero themes, the toolbars take on a purplish-blue shade, slightly purpler for some reason than the Windows 7 Basic shade I see on Windows Explorer (yes, even on Aero, even if Aero is using some other color shade for tinting the glass parts of the interface). The shiny effect on the menu bar, which seems intended to make it look slightly convex, is also a bit off. But it's generally consistent with the Aero Basic look. (Seamonkey does not support full Aero transparencies). On Aero, the hover pseudo-3D effect is slightly different, with rounded corners on the buttons (consistent with the Aero Basic look), but otherwise similar to the one in Windos Classic. The menus themselves aren't light blue, but light gray (again, consistent with the Aero look -- blame whoever at Microsoft was responsible for the UI design if you consider this a lack o consistency, Seamonkey just emulated the look). When I hover the mouse over an opened menu, the horizontal bar highlight for the hovered option is a very light blue highlight/frame, but keeping the font black (well, except for greyed out items, when the highlight is also grey, with the border of the highlight a bit darker than the usual menu background). Again, consistent with the Aero look. (Aside: It seems that the theme guys didn't _quite_ manage to reproduce the Vista/Win7 look using the Mozilla toolkit, but they did get damn close. I only notice the slight differences between the native Windows theme and the emulated version in Seamonkey because I was looking for it -- I have been using SM on Win7 for about one year and a half and never had noticed those differences). Anyway, the text on a hovered item in a drop-down menu only turned to white (over a *dark blue* background, however) when using the Windows Classic theme. On the Windows 7, the text remained black. I think gjikkl may be on to something; perhaps there is something wrong with the theming on your Windows, and the theme is not being able to interpret the cues from the OS correctly -- and ended up using an unholy mix of the Wndows Classic and Aero versions of the theme. A few things to try: - Open one of the bundled Windows applets (like Windows Explorer, or Notepad). Check the menu behavior on those and compare it to the Seamonkey behavior. - Change the theme to Windows 7 Basic. Repeat the test above. - Change the theme to Windows Classic. Repeat the test above. - Change back to one of the Aero themes - it may be the Windows 7 theme, or any one of the others (the ones with transparent glass effects, I mean). Repeat the test above to see if the change/change back theme could have fixed the issue. Still didn't work? Check with your video card/embedded card maker to see if you aren't using an old version of their driver. Some earlier drivers are notoriously buggy. Still didn't work? Well, maybe it's something wrong in your Seamonkey profile. Try creating a clean SM profile, just for test purposes. If this clean profile does not display the problem then it's a profile issue. If not... well, I'm not sure what could be causing this either. In that case, you might want to file a Bugzilla bug for
Re: Massive RAM usage
Interviewed by CNN on 18/05/2012 16:23, Beauregard T. Shagnasty told the world: The reason I asked is because your half-gigabyte is way far and above what I get from a similar number of tabs. If one is checking memory used by *tabs*, one does not normally load up a dozen different pages filled with images and videos which will skew the results. My testing page for this experiment was a simple local page of about 4 KB, opened a dozen times and resulting in less than a tenth of your version. OK, just to give something reproducible: I have a set of tabs I open daily to check my comics. Those are: http://www.gocomics.com/bloomcounty http://www.gocomics.com/calvinandhobbes http://www.dilbert.com/ http://www.gocomics.com/foxtrotclassics/ http://www.gocomics.com/libertymeadows http://www.offthemark.com/daily.php/ http://www.kevinandkell.com/ http://www.onthefastrack.com/ http://safehavenscomic.com/ http://www.gocomics.com/peanuts http://www.sheldoncomics.com/ http://www.sluggy.com/ http://ars.userfriendly.org/cartoons/ 13 pages, all containing images, some of them containing several images, some of them containing ads and other crap (although NoScript blocks quite a bit of those). Plus Seamonkey Mail, plus the message editor (Composer) where I'm writing this very post. Windows Task Manager reports 326868 K for Seamonkey plus 27824 K for plugin-container. About:memory gives this: Explicit Allocations 265.52 MB (100.0%) -- explicit ├──113.50 MB (42.75%) -- js │ ├───36.61 MB (13.79%) -- compartment([System Principal], 0x63e6000) │ │ ├──19.02 MB (07.16%) -- gc-heap │ │ │ ├───6.11 MB (02.30%) -- objects │ │ │ │ ├──3.13 MB (01.18%) ── function │ │ │ │ └──2.97 MB (01.12%) ── non-function │ │ │ ├───4.91 MB (01.85%) -- shapes │ │ │ │ ├──2.84 MB (01.07%) ── tree │ │ │ │ └──2.07 MB (00.78%) ++ (2 tiny) │ │ │ ├───4.65 MB (01.75%) ── strings │ │ │ └───3.34 MB (01.26%) ++ (4 tiny) │ │ ├───4.15 MB (01.56%) ++ (5 tiny) │ │ ├───4.06 MB (01.53%) ── script-data │ │ ├───3.38 MB (01.27%) ── analysis-temporary │ │ ├───3.10 MB (01.17%) ── string-chars │ │ └───2.92 MB (01.10%) ++ shapes-extra │ ├───19.44 MB (07.32%) ++ (40 tiny) │ ├───13.82 MB (05.20%) ── gc-heap-decommitted │ ├───11.82 MB (04.45%) -- compartment(https://plusone.google.com/_/+1/fastbutton?bsv=purl=http%3A%2F%2Fwww.onthefastrack.com%2F%3Fp%3D1592size=mediumcount=truehl=en-USjsh=m%3B%2F_%2Fapps-static%2F_%2Fjs%2Fgapi%2F__features__%2Frt%3Dj%2Fver%3D6pJQ7GZ7cYA.en.%2Fsv%3D1%2Fam%3D!tbK8W_8mwqaIodoNDQ%2Fd%3D1%2Frs%3DAItRSTNlDJtRFk-OErcH2_5IvFTLyiPUDg#id=I2_1337410450577parent=http%3A%2F%2Fwww.onthefastrack.comrpctoken=211309993_methods=onPlusOne%2C_ready%2C_close%2C_open%2C_resizeMe%2C_renderstart) │ │ ├───6.48 MB (02.44%) ++ gc-heap │ │ ├───3.20 MB (01.21%) ── script-data [2] │ │ └───2.14 MB (00.81%) ++ (7 tiny) │ ├7.74 MB (02.91%) -- compartment(http://www.gocomics.com/calvinandhobbes) │ │├──4.32 MB (01.63%) ++ gc-heap │ │└──3.42 MB (01.29%) ++ (8 tiny) │ ├4.87 MB (01.83%) ++ compartment(http://www.kevinandkell.com/) │ ├3.65 MB (01.37%) ++ compartment(atoms) │ ├3.63 MB (01.37%) ++ compartment(http://www.google.com.br/search?hl=ensource=hpq=screenshot%20seamonkey%202oq=aq=aqi=aql=gs_sm=gs_upl=) │ ├3.35 MB (01.26%) ── xpconnect │ ├2.94 MB (01.11%) ++ compartment(http://www.dilbert.com/) │ ├2.84 MB (01.07%) ++ compartment(http://www.onthefastrack.com/) │ └2.78 MB (01.05%) ++ compartment(http://safehavenscomic.com/) ├───78.29 MB (29.48%) ── heap-unclassified ├───30.45 MB (11.47%) -- storage │ └──30.45 MB (11.47%) -- sqlite │ ├──13.92 MB (05.24%) ── other │ ├──13.80 MB (05.20%) -- places.sqlite │ │ ├──13.41 MB (05.05%) ── cache-used [3] │ │ └───0.39 MB (00.15%) ++ (2 tiny) │ └───2.73 MB (01.03%) ++ (11 tiny) ├───14.17 MB (05.34%) -- images │ ├───8.13 MB (03.06%) -- content │ │ ├──8.13 MB (03.06%) -- used │ │ │ ├──5.40 MB (02.04%) ── raw │ │ │ ├──2.73 MB (01.03%) ── uncompressed-heap │ │ │ └──0.00 MB (00.00%) ── uncompressed-nonheap │ │ └──0.00 MB (00.00%) ++ unused │ └───6.03 MB (02.27%) -- chrome │ ├──6.03 MB (02.27%) -- used │ │ ├──6.03 MB (02.27%) ── uncompressed-heap │ │ └──0.00 MB (00.00%) ++ (2 tiny) │ └──0.00 MB (00.00%) ++ unused ├───13.40 MB (05.05%) ++ layout ├8.05 MB (03.03%) -- dom │├──4.78 MB (01.80%) -- window-objects ││ ├──4.50 MB (01.70%) ++ active ││ └──0.28 MB (00.11%) ++ (2 tiny) │└──3.27 MB (01.23%) -- workers() │ └──3.27 MB (01.23%) ++ worker(chrome://ghostery/content/ghostery-scanner.js, 0xef044000ef04400) ├4.85 MB (01.83%) ++ (6 tiny) └2.81 MB (01.06%) -- startup-cache ├──2.81 MB (01.06%) ── mapping └──0.00 MB (00.00%) ── data Other Measurements 0.22 MB ── canvas-2d-pixel-bytes 265.53 MB ── explicit 7.69 MB ── gfx-d2d-surfacecache 29.55 MB ── gfx-d2d-surfacevram 8.36 MB ──
Re: Massive RAM usage
Beauregard T. Shagnasty wrote: gjikkl wrote: Beauregard T. Shagnasty wrote: gjikkl wrote: Ed Mullen wrote: Win 7 32-bit, 4Gb RAM, SM 2.9.1. 12 tabs open. 155,740 Kb of RAM used. Win 7 64-bit, 4Gb RAM, SM 2.9.1. 18 tabs open. 519,296 Kb of RAM used. Pray tell, what pages are opened in those 18 tabs? Sorry I can't. Because you don't want to reveal, or because you can't remember? The reason I asked is because your half-gigabyte is way far and above what I get from a similar number of tabs. If one is checking memory used by *tabs*, one does not normally load up a dozen different pages filled with images and videos which will skew the results. My testing page for this experiment was a simple local page of about 4 KB, opened a dozen times and resulting in less than a tenth of your version. Beauregard, just for interest, I've checked three of my homepage group:- http://www.ebroadcast.com.au/TV/static/VICRegNight.html http://www.bom.gov.au/products/IDR492.shtml http://www.bom.gov.au/products/IDR492.shtml and, in a fourth tab, about:memory tells me I'm using about 665MB vsize. Is this what you were asking for?? Mozilla/5.0 (X11; Linux i686 on x86_64; rv:12.0) Gecko/20120429 SeaMonkey/2.9.1 -- Daniel ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Massive RAM usage
MCBastos wrote: Beauregard T. Shagnasty told the world: The reason I asked is because your half-gigabyte is way far and above what I get from a similar number of tabs. If one is checking memory used by *tabs*, one does not normally load up a dozen different pages filled with images and videos which will skew the results. My testing page for this experiment was a simple local page of about 4 KB, opened a dozen times and resulting in less than a tenth of your version. OK, just to give something reproducible: I have a set of tabs I open daily to check my comics. Those are: snip 13 pages, all containing images, some of them containing several images, some of them containing ads and other crap (although NoScript blocks quite a bit of those). Plus Seamonkey Mail, plus the message editor (Composer) where I'm writing this very post. Windows Task Manager reports 326868 K for Seamonkey plus 27824 K for plugin-container. About:memory gives this: Explicit Allocations 265.52 MB (100.0%) -- explicit snip Thanks to you and Daniel for the test. This seems to prove that the amount of RAM in use is more-or-less dependent on *what pages* are loaded in the ~12 tabs, and not actually any kind of fault of the browser or the tabs themselves. If one loads pages containing lots of unknown images of various file sizes and other multimedia, the memory usage will be high. Keep in mind, too, that any pages that have that silly Facebook Like button, there's another over-a-quarter-megabyte of JavaScript, each. As I said, my test involved a dozen tabs each with a small ~4KB page (no images, only text and links), and the total amount of RAM used by SeaMonkey was ~50MB. I don't see a browser issue here. -- -bts -This space for rent, but the price is high ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Massive RAM usage
Beauregard T. Shagnasty wrote: MCBastos wrote: Beauregard T. Shagnasty told the world: The reason I asked is because your half-gigabyte is way far and above what I get from a similar number of tabs. If one is checking memory used by *tabs*, one does not normally load up a dozen different pages filled with images and videos which will skew the results. My testing page for this experiment was a simple local page of about 4 KB, opened a dozen times and resulting in less than a tenth of your version. OK, just to give something reproducible: I have a set of tabs I open daily to check my comics. Those are: snip 13 pages, all containing images, some of them containing several images, some of them containing ads and other crap (although NoScript blocks quite a bit of those). Plus Seamonkey Mail, plus the message editor (Composer) where I'm writing this very post. Windows Task Manager reports 326868 K for Seamonkey plus 27824 K for plugin-container. About:memory gives this: Explicit Allocations 265.52 MB (100.0%) -- explicit snip Thanks to you and Daniel for the test. This seems to prove that the amount of RAM in use is more-or-less dependent on *what pages* are loaded in the ~12 tabs, and not actually any kind of fault of the browser or the tabs themselves. If one loads pages containing lots of unknown images of various file sizes and other multimedia, the memory usage will be high. Keep in mind, too, that any pages that have that silly Facebook Like button, there's another over-a-quarter-megabyte of JavaScript, each. As I said, my test involved a dozen tabs each with a small ~4KB page (no images, only text and links), and the total amount of RAM used by SeaMonkey was ~50MB. I don't see a browser issue here. Beauregard, just for a further test, so you would know how much graphics, etc, is loaded in the viewed pages, I just opened twelve tabs all addressed to http://www.seamonkey-project.org/. vsize 668MB .. which is roughly the same as what I was getting for my earlier three tabs!! -- Daniel ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Massive RAM usage
Daniel wrote: Beauregard, just for a further test, so you would know how much graphics, etc, is loaded in the viewed pages, I just opened twelve tabs all addressed to http://www.seamonkey-project.org/. vsize 668MB .. which is roughly the same as what I was getting for my earlier three tabs!! Thanks for the further test. That page (a single instance) is 79KB uncompressed. My page is 9KB, and this seems to solidify my theory. :-) -- -bts -This space for rent, but the price is high ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: After 2.9.x upgrade, slower to empty Junk folder
Greetings, I also noticed SM 2.9.1 running on Windows XP Pro with NTFS is equally slower about deleting all messages from the Junk folder. So this is a cross-platform observation. What happened between the 2.8.x series and the 2.9.x series that would make deleting all Junk messages extremely slower? Sincerely, -- Michael Lueck Lueck Data Systems http://www.lueckdatasystems.com/ ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Massive RAM usage
Daniel wrote: gjikkl wrote: Jean Zebloski wrote: Why would Seamonkey be chewing up 430 megs of RAM all the time? Because it makes ineficient use of cache, but works toward that has been initiated and they say will continue to improve over time, for now he have to settle for a FAT SEAMONKEY, that's getting thiner VERY SLOWLY. Sorry, about:memory tells me my SeaMonkey is using approx 625MB of (vsize) memory, but does not list anything about the cache size!! about:cache should help there ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: View Source
David E. Ross wrote: Can the display of a page source be made consistent, preferably with the entity references untranslated? I would think that View Source should do exactly that... Show the actual Source code which produces the page, errors or otherwise left as-was. No search and replace type translation should be performed on the output of View Source. So is SM actually translating anything? Have you done a wget of the URL in question and compare outputs? -- Michael Lueck Lueck Data Systems http://www.lueckdatasystems.com/ ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: View Source
On 5/19/12 10:31 AM, Michael Lueck wrote: David E. Ross wrote: Can the display of a page source be made consistent, preferably with the entity references untranslated? I would think that View Source should do exactly that... Show the actual Source code which produces the page, errors or otherwise left as-was. No search and replace type translation should be performed on the output of View Source. So is SM actually translating anything? Have you done a wget of the URL in question and compare outputs? I don't have to do a wget. I tried it on one of my own pages. I keep a complete copy of my Web site on the hard drive of my PC. I see this problem when I want to copy some markup from an existing Web page into another page. This is easily done by marking the content in a rendered page and then viewing the source (right-click, View Selection Source on the pull-down context menu). The marked content is then marked in the source, so all I have to do is copy and paste. I do not see this problem when I go to the SeaMonkey menu bar and select [View Page Source]. Then it seems that all entity references remain untranslated. -- David E. Ross http://www.rossde.com/. Anyone who thinks government owns a monopoly on inefficient, obstructive bureaucracy has obviously never worked for a large corporation. © 1997 by David E. Ross ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: View Source
David E. Ross wrote: I do not see this problem when I go to the SeaMonkey menu bar and select [View Page Source]. Then it seems that all entity references remain untranslated. Then that should be the way you get your copy. What are you using for an editor (which could also affect what is happening)? Why don't you get the copy from the editor instead of a viewed page? Seems backwards to me to do it your way. :-/ -- -bts -My web sites are on my drive too -because that is the master copy ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Massive RAM usage
Paul B. Gallagher pau...@pbgdashtranslations.com wrote : Rostyslaw Lewyckyj wrote: But if GerardJan has (only) 4Mbytes of physical memory, how does he fit that 41 meg tab into it? If he has only 4 MB of RAM, he's running a wristwatch, not a computer. He must've meant 4 GB. Of course. Hey, I still have some 4k RAM chips on the shelf, from 1978, if I recall. :) ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Massive RAM usage
Ed Mullen e...@mungeedmullen.net wrote : Gerard had to have mis-typed. No modern PC has anything less than 512 Mb to 1 Gb of RAM. My PC (one of five) has 4 GIGA-bytes of RAM. resolved, yes ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Massive RAM usage
Beauregard T. Shagnasty a.nony.mous@example.invalid wrote : Gerard had to have mis-typed. No modern PC has anything less than 512 Mb to 1 Gb of RAM. GerardJan frequently does. He has also freely admitted that he occasionally forgets his medication. ;-) My PC (one of five) has 4 GIGA-bytes of RAM. Yes, the OP said, if I recall, 8GB of RAM and each SM tab was using about 40 megs when there were 12 open? Wasn't it 440 or so megs total? ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Massive RAM usage
gjikkl saul...@netscape.net wrote : Jean Zebloski wrote: Why would Seamonkey be chewing up 430 megs of RAM all the time? Because it makes ineficient use of cache, but works toward that has been initiated and they say will continue to improve over time, for now he have to settle for a FAT SEAMONKEY, that's getting thiner VERY SLOWLY. People keep saying to just give it up and use Firefox. With the interminably slow bookmarks loading in SM, I'm getting to agree with them. ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Massive RAM usage
Barry Edwin Gilmour barrygilm...@bigpond.com wrote : Daniel wrote: gjikkl wrote: Jean Zebloski wrote: Why would Seamonkey be chewing up 430 megs of RAM all the time? Because it makes ineficient use of cache, but works toward that has been initiated and they say will continue to improve over time, for now he have to settle for a FAT SEAMONKEY, that's getting thiner VERY SLOWLY. Sorry, about:memory tells me my SeaMonkey is using approx 625MB of (vsize) memory, but does not list anything about the cache size!! about:cache should help there Information about the Cache Service Memory cache device Number of entries: 134 Maximum storage size: 32768 KiB Storage in use: 219 KiB Inactive storage: 219 KiB List Cache Entries Disk cache device Number of entries: 72657 Maximum storage size: 1048576 KiB Storage in use: 807993 KiB \q6uia1cf.default\Cache List Cache Entries Offline cache device Number of entries: 0 Maximum storage size: 512000 KiB Storage in use: 0 KiB ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Massive RAM usage
Beauregard T. Shagnasty a.nony.mous@example.invalid wrote : gjikkl wrote: Ed Mullen wrote: Win 7 32-bit, 4Gb RAM, SM 2.9.1. 12 tabs open. 155,740 Kb of RAM used. Win 7 64-bit, 4Gb RAM, SM 2.9.1. 18 tabs open. 519,296 Kb of RAM used. Pray tell, what pages are opened in those 18 tabs? Here's 10 blank Google search pages: Information about the Cache Service Memory cache device Number of entries: 134 Maximum storage size: 32768 KiB Storage in use: 219 KiB Inactive storage: 219 KiB List Cache Entries Disk cache device Number of entries: 72667 Maximum storage size: 1048576 KiB Storage in use: 808033 KiB Cache Directory:... \q6uia1cf.default\Cache List Cache Entries Offline cache device Number of entries: 0 Maximum storage size: 512000 KiB Storage in use: 0 KiB Cache Directory:... \q6uia1cf.default\OfflineCache ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Massive RAM usage
Interviewed by CNN on 20/05/2012 01:10, Libertarian Lilly told the world: gjikkl saul...@netscape.net wrote : Jean Zebloski wrote: Why would Seamonkey be chewing up 430 megs of RAM all the time? Because it makes ineficient use of cache, but works toward that has been initiated and they say will continue to improve over time, for now he have to settle for a FAT SEAMONKEY, that's getting thiner VERY SLOWLY. People keep saying to just give it up and use Firefox. With the interminably slow bookmarks loading in SM, I'm getting to agree with them. Uh? I don't notice that, and I have quite a few bookmarks. The menu just snaps open. Anyway, Firefox has been on a diet for the last year. Only it's not really Firefox who is on a diet, but Gecko. Which means that Seamonkey should reap most of the benefits too. However, there is a delay between an improvement being announced as landed and it actually showing up in a release version. For instance, there was recently an announcement of a patch that greatly reduces the problem of add-ons leaking memory. Only, of course, the patch landed on the *trunk*. Which means that it won't see the light of the day until Firefox 15, scheduled for August 15 I believe (Current Beta version is FF 13, Aurora is FF 14). That is, if no serious problems are found with this patch while undergoing the Aurora and Beta stabilization phases. If a serious problem is found, this feature might be delayed a bit more. But it's a Gecko patch, meaning that if FF 15 has it, SM 2.12 (also due in August) should have it too. -- MCBastos This message has been protected with the 2ROT13 algorithm. Unauthorized use will be prosecuted under the DMCA. -=-=- ... Sent from my Apple Pippin. * Added by TagZilla 0.7a1 running on Seamonkey 2.9 * Get it at http://xsidebar.mozdev.org/modifiedmailnews.html#tagzilla ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
