This behavior is nonlinear with respect to the number of open browser tabs more tabs cause the problem to be worse way out of proportion to the tab count. My wife sees it also on a different computer. This is version 2.46, though I think it started for me with 2.40. This continues until it is no longer possible to c lose Seamonkey with either the keyboard or the mouse, and eventually it traps and the message about having to emanates from Windows.ĭuring this, which is moderately consistent, there are no videos, no audios, flash is blocked, repeating GIFS and other such ad stuff is disabled, so there is very little apparently going on. If I then try to use the browser, the performance becomes slower, and eventually loses keyboard functionality almost completely. I tend to run the browser with two open windows, each with around 10 to 15 tabs open, along with the mail window.Įven when I minimize all three Seamonkey windows, with Task Manager showing the Details screen, and I am not doing any typing or mousing, I see the memory usage increasing first slowly, then faster and faster, with the CPU utilization climbing from the 12% range into the 20% range, and the memory usage climbing from around 400 MB.Īfter some time, not very precise, memory climbs to around 2 GB or more. I think this applies mostly to the browser.
#Seamonkey 2.46 software#
Since Gecko 49.0 (Firefox 49.0 / Thunderbird 49.0 / SeaMonkey 2.46) the preference defaults to true.I have been a user of Seamonkey for a long time, since the mid version 1.X versions.Īmong other things, I am a software developer, but not on Seamonkey. In addition to the unprefixed support, Gecko 44.0 (Firefox 44.0 / Thunderbird 44.0 / SeaMonkey 2.41) added support for a -webkit prefixed version of the property for web compatibility reasons behind the preference, defaulting to false.
Prior to Gecko 50.0 (Firefox 50.0 / Thunderbird 50.0 / SeaMonkey 2.47), border styles of rounded corners were always rendered as if border-style was solid.
This implied that -moz-border-radius-bottomleft was always drawing an arc of circle, and never an ellipse, when followed by a single value. Before Firefox 4, the was relative to the width of the box even when specifying the radius for a height). The prefixed version (allowed from Firefox 1 to Firefox 12) of this property uses a different name, -moz-border-radius-bottomleft, than the final property as Mozilla implemented it before the final name was coined. The unique non-ambiguous order defined by the formal grammar Yes, as a length, percentage or calc() when both values are lengths, they are interpolated as lengths when both values are percentages, they are interpolated as percentages otherwise, both values are converted into a calc() function that is the sum of a length and a percentage (each possibly zero), and these calc() functions have each half interpolated as real numbers. Refer to the corresponding dimension of the border box The behavior on internal table elements is undefined for the moment. If the value of this property is not set in a border-radius shorthand property that is applied to the element after the border-bottom-left-radius CSS property, the value of this property is then reset to its initial value by the shorthand property.Īll elements but User Agents are not required to apply to table and inline-table elements when border-collapse is collapse.
0 kommentar(er)
