The Official Win32 20120819 builds are out

[Arjen87]

Previous Nightly Builds thread 20120818 | A couple of notes about the Nightly thread. | Nightly Build thread RSS feed (courtesy DaCypher)

The Official Win32 20120819 NIGHTLY build is out. Changeset: 8c85c83068e7
The Official Win32 20120819 AURORA build is out. Changeset: e967498a5737
.The Official Firefox 15 BETA 6 build 1 builds are not yet out Changeset: 235b96a25ef0

Previous NIGHTLY 20120818 (FF17.0a1)
Previous AURORA 20120818 (FF16.0a2)
Previous BETA 20120815 (FF15.0b5)

Hourly NIGHTLY builds: mozilla-central-linux | mozilla-central-macosx | mozilla-central-win32 | Firefox Tinderbox | NIGHTLY Changelog
Hourly NIGHTLY archive for Windows, Mac and Linux (not the final format yet)
AURORA Tinderbox | AURORA changelog

Last update: 2012-08-19 -- 00:00 PDT = 07:00 UTC

Fixed:

NIGHTLY

1. #553102 [Core:XPConnect]-Flip __exposedProps__ default for non-WN objects to default-safe [All]
2. #730085 [Core:JavaScript Engine]-Object.prototype.hasOwnProperty calls ToString on first argument before calling ToObject on this [All]
3. #773435 [Core:General]-Remove a few extraneous nsIImageLoadingContent includes [All]
4. #781153 [Core:DOM]-ArchiveReader doesn't support zip-in-zip archives [All]
5. #782908 [Core:Graphics: Text]-Update harfbuzz to current version [Lin]
6. #783016 [Core:JavaScript Engine]-Make space for Int32 string type [All]
7. #783147 [Core:JavaScript Engine]-Collect telemetry to measure the effectiveness of bug 780960 [All]
8. #783421 [Core:JavaScript Engine]-Crash [@ js::mjit::JITScript::chunkIndex] or [@ js::mjit::Recompiler::patchFrame] or "Assertion failure: found," [All]
9. #783441 [Core:JavaScript Engine]-"Assertion failure: bi->aliased()," [Mac]
10. #783497 [Core:DOM: Core & HTML]-refinePolicy doesn't respect other directives except default-src [Lin]
11. #783532 [Core:DOM]-Remove DOMError::CreateForDOMExceptionCode [All]
12. #783537
13. #783700 [Core:Layout]-nsColumnSetFrame::BuildDisplayList should use nsFrameList::Enumerator to enumerate children [All]
14. #783738 [Core:General]-Use Components.results.NS_BINDING_ABORTED instead of hardcoding the value [All]

AURORA
None

BETA
None

Partial Landings/WIPs/Incoming:

NIGHTLY

1. #751809 BACK OUT [Core:Plug-ins]-click does not work on a plugin content when a plugin is just activated [Mac]
   
   
2. #462300 [Core:JavaScript Engine]-Self-host Array.prototype.join and other JS builtins [All]
3. #770945 [Core:Video/Audio]-"Simple events" on HTML5 media shouldn't be cancelable [All]

AURORA
None

BETA
None

Regressions/Annoying/Common bugs:

None

Nightly 17.0a1 fixes since 20110322 (mozilla 2.2) = ~8830
Aurora 16.0a2 fixes since 20110322 (mozilla 2.2) = ~8225
Beta 15.0b fixes since 20110322 (mozilla 2.2) = ~7339

Release tracking Firefox 15-18 see HERE

[TheVisitor]

LordStriker posted yesterday:

Do you feel a slowness when you try to change tab ( ctrl + tab or simply clicking ) ? It's a couple of days, now, that behaves like that.

It's not as responsive as it was.

pal-moz noted it was bug: https://bugzilla.mozilla.org/show_bug.cgi?id=776090
Huge lag and slow when switch tab(ctrl+tab), switch window(Alt+tab/Click taskbar button) and move dialog window if HWA enabled

Reading the bug, turning azure.content in about:config does not resolve the lag problem. I suspect this is no the correct bug for the lag we're seeing when switching to some tabs.

STR:
1. open http://www.nbcnews.com
2. open http://www.cnn.com
3. have forum open in a tab
4. switching from the mz forum to either tab 1 or 2 will show about 1 sec delay in switching.
5. if you then quickly switch between the forum and CNN for example - switching is pretty fast.
6. switch to forum tab - wait 10-15 seconds then switch to either CNN or NBCnews - note it lags

Seems that after a short pause in tab switching re-triggers the delay on the next switch to that tab. Seems it is related to pages with heavy javascript and images.

As noted, this started just a few days ago, and azure.content has been awhile now. I more suspect DLBI or
https://bugzilla.mozilla.org/show_bug.cgi?id=683290 <- We won't discard any images on the current tab even if they are not in the DOM

EDIT: Possible regression range:
20120815033901 1340cabb01d1 no lag
20120815065301 d67c02074ced lags

the build that does not lag is before bug 683290 landed, the other build that does lag includes the bug 683290 and others.

cset http://hg.mozilla.org/mozilla-central/rev/a0bddf5fcb91 was the m-c -> b-s merge on Wed Aug 15 06:26:57

[LordStriker]

I'm not so sure with HWA being disabled, the problem disappears; but anyway.

They know better.

[Alice0775]

LordStriker posted yesterday:

Do you feel a slowness when you try to change tab ( ctrl + tab or simply clicking ) ? It's a couple of days, now, that behaves like that.

It's not as responsive as it was.

pal-moz noted it was bug: https://bugzilla.mozilla.org/show_bug.cgi?id=776090
Huge lag and slow when switch tab(ctrl+tab), switch window(Alt+tab/Click taskbar button) and move dialog window if HWA enabled

Reading the bug, turning azure.content in about:config does not resolve the lag problem. I suspect this is no the correct bug for the lag we're seeing when switching to some tabs.

STR:
1. open http://www.nbcnews.com
2. open http://www.cnn.com
3. have forum open in a tab
4. switching from the mz forum to either tab 1 or 2 will show about 1 sec delay in switching.
5. if you then quickly switch between the forum and CNN for example - switching is pretty fast.
6. switch to forum tab - wait 10-15 seconds then switch to either CNN or NBCnews - note it lags

Seems that after a short pause in tab switching re-triggers the delay on the next switch to that tab. Seems it is related to pages with heavy javascript and images.

As noted, this started just a few days ago, and azure.content has been awhile now. I more suspect DLBI or
https://bugzilla.mozilla.org/show_bug.cgi?id=683290 <- We won't discard any images on the current tab even if they are not in the DOM

EDIT: Possible regression range:
20120815033901 1340cabb01d1 no lag
20120815065301 d67c02074ced lags

the build that does not lag is before bug 683290 landed, the other build that does lag includes the bug 683290 and others.

cset http://hg.mozilla.org/mozilla-central/rev/a0bddf5fcb91 was the m-c -> b-s merge on Wed Aug 15 06:26:57

Maybe https://bugzilla.mozilla.org/show_bug.cgi?id=783748

[TheVisitor]

snip

Maybe https://bugzilla.mozilla.org/show_bug.cgi?id=783748

Yes, appears to be so, thanks Alice...

[BruceAWittmeier]

Im on Win32 and do not have the problem switching tabs. However, page loading such as the Mozillazine index page takes about 15-20 seconds whereas about a week ago Fx was - well - on Fire blazing fast.

This build:
Built from http://hg.mozilla.org/mozilla-central/rev/812ea773f166

[Sanni]

Does Ringmark (http://ringmark.io/) Ring 0 broken for anyone else?
Geolocation methods...

[Dingler]

Yes, but I'm not sure if Firefox is really broken or if Ringmark has updated its benchmark, because the last time I checked, FF17 passed all the ring 0 like FF14. Now, FF14 & FF17 don't pass geolocation.
In addition, they fixed their website to display the results (that was broken on Nightly).

[Sanni]

Yes, but I'm not sure if Firefox is really broken or if Ringmark has updated its benchmark, because the last time I checked, FF17 passed all the ring 0 like FF14. Now, FF14 & FF17 don't pass geolocation.
In addition, they fixed their website to display the results (that was broken on Nightly).

But it's the same version of RIngmark (1.4.0)...
I'm checking almost daily, yesterday or two days ago all was fine. May be they changed smthing without version change?
I have the impression that this is working on Linux, I'll re-check when I'll be back home.

[Dingler]

I think Ringmark updated its website because I found no regression in Firefox (now ring 0 fails in every version).

[juzz]

Yes, but I'm not sure if Firefox is really broken or if Ringmark has updated its benchmark, because the last time I checked, FF17 passed all the ring 0 like FF14. Now, FF14 & FF17 don't pass geolocation.
In addition, they fixed their website to display the results (that was broken on Nightly).

I think it's ringmark specific problem

https://google-developers.appspot.com/m ... eolocation works for me so the geolocation itself seems to be working with firefox.

Maybe ringmark expects more accurate results (as its mobile test afterall so expecting GPS accuracy?).

Also https://developer.mozilla.org/en-US/doc ... eolocation test suggested from here --> http://www.thedotproduct.org/experiments/geo/ gives error: Accuracy not sufficient (18000m vs 150m) - last reading taken at: 13:55:03

So maybe its just issue with nonmobile devices giving too inaccurate results because no gps? But to be honest I have no idea will it be any more accurate with mobile devices and don't have one to test with right now.

[kilara1988]

It's definitely the sites fault since Chrome and IE too fail at the exactly the same 3 geolocation tests(IE fails on a lot more others too).

[LordStriker]

http://commondatastorage.googleapis.com ... ?path=Win/

Here as you might know, you get the latest Chromium build. Firefox always has been struggling to load, but eventually the loading was complete.

Currently it keeps loading forever. It might be useful to know about this regression, I guess.

P.S. The entire UI is freezing, you've been warned ( in case you wanna try for first time to load the website ).

[WildcatRay]

Win32 Nightly is out: http://hg.mozilla.org/mozilla-central/rev/8c85c83068e7

[Arjen87]

This thread is closed, please use the next one.