2006-03-18 Trunk builds


  • Fixed: 187772 - Mouse wheel scrolling does not dismiss form auto complete history, results in floating autocomplete dropdown.
  • Fixed: 216434 - Autocomplete dropdown covers textbox when textbox is near bottom of screen.
  • Fixed: 330738 - Update in-tree cairo to current cairo head.

Fixes for recent regressions:

  • Fixed: 330802 - Dragging link to toolbar or menu broken again in Places.

Trunk regressions:

  • Since ~Mar 17: 330929 - "Bookmark all tabs" broken.
  • Since Mar 2 (Places): 330125 - Address bar autocomplete no longer sorts by number of visits.
  • Since Mar 2 (Places): 330126 - Address bar autocomplete omits many URLs.
  • Since Cairo: 330715 - Cairo incorrectly substitutes fonts and then bolds them incorrectly (incorrect fonts on Burning Edge bug lists).
  • Since Cairo: 324707 - Some animated gifs including the throbber don't animate.
  • Since Cairo: 324706 - Bitmap fonts don't render in cairo builds.
  • Since Cairo: 324560 - Can't see many Unicode characters in Cairo.
  • Since Cairo: 328241 - Anti-aliasing problem with joining borders.
  • Since Jan 31: 324961 - Live bookmark is shown in UTF8 even if should be ISO-8859-1.
  • Since Jan 26 (FDL): [Mac] Opacity doesn't work. (Related to 325296. Cairo will fix.)
  • Since Jan 26 (FDL): 324819 - Fixed positioned elements now lag/flicker when scrolling.
  • Since Jan 26 (FDL): 324963 - [Windows] Menu highlight is broken/doesn't show up/not painted.

Trunk checkins between 2006-03-17 06:00 and 2006-03-18 06:00

Windows builds: Windows nightly, Windows hourly (discussion)

Linux builds: Linux nightly Linux hourly

Mac builds: Mac nightly, Mac hourly

5 Responses to “2006-03-18 Trunk builds”

  1. nestastnik Says:

    http://www.ASP.NET/forums/ HOROR return !

    off-topic, but since jessee no longer follows stabile branch, I post it here.

    After a few browsing, max 30 minutes of forums, I got 700 MB commit with disk swapping all the time and 400 MB peak memory usage of FF with only around 8 tabs opened. Considering I was just on ONE page with ONE cachce with ONE DOM etc, the leakeage is horrible. So testers if you’ve got time, try it, I’ve reported few times and It thought it was fixed. But then asp.net got a ‘new’ CommunityServer2 version to run its core forums, so bugs are here again.

    Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv: Gecko/20060326 Firefox/

  2. nestastnik Says:

    OK, found a complete way to debug a bug.

    1. visit http://forums.asp.net/ and pick any thread.
    2. Open 10 tabs from it – we are on around 40MB/70MB peak.
    3. Then BOOKMARK ALL Tabs.
    4. Then exit FF.
    5. Start FF.
    6. Open all tabs AT ONCE from bookmarks.
    7. Wait a bit till all tabs refreshed at the same time.
    8. This is the end, my only friend…

    we now have 400MB usage and big disk swapping…

    Jesse, if you would be so kind and report this bug, I can’t seem to have power to get it noticed or I don’t know the correct way. But this bug is really really serious and very easy to debug (the memory leak happens on automatic_page_refresh event or something). Thank you. Firefox version above (e.g. stable branch witch should have many memory bugs fixed from 1.5.0)

  3. Jason Meller Says:

    I followed your above steps and this WFM. After opening up all the tabs at once firefox uses the same amount memory it did previously while I bookmarked the pages (about 40MB)

    Maybe this is a regression from to

    I’d try it in safe-mode to see if you get the same result.

    Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20060111 Firefox/

  4. nestastnik Says:

    Jason, you need to wait IDLE on this forum, for around 10 minutes or so…it has autorefresh. After opening all the tabs firefox is O.K. for a while. The automatic refresh of those tabs (not yours but ASP.NET one!) at once (that is why you needed to bookmark it) will cause the bug.

  5. Jason Meller Says:

    Okay, now I see the issue. The memory usage seems to sway from 20 – 100 MB BUT firefox hangs like crazy and page file usage i through the roof until the program becomes unresponsive. This must be a bug as all those tabs should load in the same amount of time as it took to load them initially.

    Maybe if we can come up with a quick test case…