updates Meet the browser: Chrome Next

[.stan]

You can read changelogs just fine, I use http://git.chromium.org/gitweb/?p=git/chromium.git;a=rss

[+Zlip792 MVC]

You can read changelogs just fine, I use http://git.chromium.org/gitweb/?p=git/chromium.git;a=rss

 

Better one: http://git.chromium.org/gitweb/?p=chromium.git;a=shortlog

 

So they shifted to more like Mercurial system like Firefox.

 

Although unlike Firefox where they include Bug number as well, there is no such things.

 

Not to mention, its something but not like before where in single XML we can read Blink Changes and v8 changes as well, now we have to see commit message and open URL in tab to read particular changeset changes.

 

In short, it could be said that its something better than nothing but its still not up to the transparency level like before and convenience.

[Boo Berry]

Oh, that's handy. Now they just need to fix the building of continuous builds. Maybe a bug should be filed?

[+Zlip792 MVC]

Oh, that's handy. Now they just need to fix the building of continuous builds. Maybe a bug should be filed?

 

I asked them on "chromium-discuss" Google Group but none bother to reply... You can file bug if you will be lucky you would get reply.

 

https://groups.google.com/a/chromium.org/forum/#!forum/chromium-discuss

 

My Post: https://groups.google.com/a/chromium.org/forum/#!topic/chromium-discuss/SVHS4t6A5L0

 

You can also ask them on "chromium-dev" Group - https://groups.google.com/a/chromium.org/forum/#!forum/chromium-dev

[.stan]

It's git not mercurial, and you can also use http://omahaproxy.appspot.com/ to get a lot of diffs and logs. There are already bugs filed for everything you guys mentioned, things just have to be handled differently with git providing the version numbers because hashes are not incremental numbers like svn revision numbers.

 

You can browse https://code.google.com/p/chromium/issues/list?can=2&q=label%3AInfra-Chrome&colspec=ID+Pri+M+Iteration+ReleaseBlock+Cr+Status+Owner+Summary+OS+Modified&cells=tiles and look at the bugs.

[Boo Berry]

A new 64-bit build came out, yay!

[LittleNeutrino Veteran]

I was about to ask how you know its x64 and then i went to about and it sayd (x64)

[+Zlip792 MVC]

A new 64-bit build came out, yay!

 

But one problem still remains... Its no changelog availability...

[Boo Berry]

Changelogs are working and displaying correctly again with the latest continuous builds.

[BooBerry]

With Chrome 37 comes a change to how offline mode works in the browser. Offline Mode will be enabled by default starting with Chrome 37 which means that the experimental flag will no longer be provided.

 

The Chromium team has added three new experimental flags to the browser which you can use to enhance the feature further:

    chrome://flags/#enable-offline-auto-reload - If enabled, Chrome will keep track of pages that you visit while offline. This can be the case if you visit a link on a cached page that is not cached. The page fails to load because of that. Chrome remembers the page and will download it once an Internet connection is available so that you can access it next time the Internet becomes unavailable.

    chrome://flags/#enable-offline-auto-reload-visible-only - This works similar to the flag above but with the difference that only visible tabs will be loaded when Internet access becomes available.

    chrome://flags/#enable-offline-load-stale-cache - This is the preference that determines whether the show saved copy button is displayed on the connection error page. It is enabled by default, and you can use the preference to disable it.
 

[BooBerry]

Google has added a feature to Chrome recently that allows you to lock down the browser using your Google password. While that may sound like a good idea, it has implications which you need to know about:

1. Since you are linking your Google account to a profile, it is necessary to stay logged in whenever you use that profile in Chrome. This means that you are always signed in to Google when you use the feature.
2. While you can lock your Chrome profile so that it cannot be accessed, you too cannot use Chrome at that time.
3. You need to manually lock Chrome, there is no option to do this automatically (for instance when the computer goes to sleep or is turned off)
4. The feature is experimental at the time of writing which means that it may or may not be integrated natively in the browser.
5. Load chrome://flags/#enable-new-profile-management in the address bar and switch the preference to enabled. This enables the browser's new profile management.
6. Click on the restart button to apply the change and relaunch the browser.

You will see a profile menu at the top right corner of the screen on restart.

 

• Here you need to sign-in to a Google account using your account credentials.
• Once you have done so, you see your profile picture and name listed in the menu.
• Here you also find the lock button which you can click on to lock down the browser.
• This switches Chrome to the user manager window that displays options to sign in again, create a new account, or browse as guest.
• This page will remain until you sign in again or use one of the other options provided on the screen. It remains active when you close Chrome so that you can use it to lock down your browser profile completely using the feature.

[BooBerry]

Another interesting option that is provided by this new user management feature is the option to make available a guest browsing mode to others.

[BooBerry]

Google to Fix Chrome Bug Killing Windows Laptop Battery

 

 

Google Chrome actually modifies system clock tick rates in Windows, thus making the processor wake up more often to check for events that might require additional power. Hence, increased battery consumption.

[BooBerry]

 Switched to BoringSSL.

[+Zlip792 MVC]

Google to Fix Chrome Bug Killing Windows Laptop Battery

 

 

Google Chrome actually modifies system clock tick rates in Windows, thus making the processor wake up more often to check for events that might require additional power. Hence, increased battery consumption.

 

 

If anyone wants to see how its worse and detailed explanation, I recommend to read following blogpost: http://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted/

I think this work will be underway because of this project: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/P5LTJRwUhpQ

 

On side note:

--- Chrome improved drag'n'drop behavior on Linux and Google ChromeOS matching Windows

--- Chrome is shifting complex stuff like marquee (HTMLMarqueeElement) on JS inside Blink layout engine (blink-in-js).

 

@Boo Berry

 

Bad news, Chrome x64 continuous builds also shifted to Git now...

[.stan]

If anyone wants to see how its worse and detailed explanation, I recommend to read following blogpost: http://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted/

I think this work will be underway because of this project: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/P5LTJRwUhpQ

 

On side note:

--- Chrome improved drag'n'drop behavior on Linux and Google ChromeOS matching Windows

--- Chrome is shifting complex stuff like marquee (HTMLMarqueeElement) on JS inside Blink layout engine (blink-in-js).

 

@Boo Berry

 

Bad news, Chrome x64 continuous builds also shifted to Git now...

Jeez, stop calling it bad news just because it takes some time till all tools are sorted :p

 

Moving everything to git is a huge undertaking for Google and will be a huge profit when they are done.

[Boo Berry]

Yeah, I noticed that.

 

On the bright side, looks like more stuff for smooth scrolling is inbound.

[BooBerry]

Refactor RTCP handling



This change is to refactor RTCP handling in media/cast such that RTCP
message parsing is done in CastTransportSender.

This side effect of this refactoring is much cleaner code: RTCP handling
code are grouped under one module. VideoSender and AudioSender do not
handle packets directly.

This also affect the architectutre in Chrome that RTCP message parsing
is now done in the browser process. A parsed RTCP message is passed to
the renderer instead of raw packets.

REATIONALE

RTCP is used as a feedback mechanism in Cast Streaming. It used to be
parsed and handled by VideoSender and AudioSender in the render process.
This was very ineffective because packetization and sending is done in
the browser process. This created inefficiencies in packet
retransmission. It also made improvement to the transport protocol /
algorithm much more difficult. A side effect is very messy code.



Net deleted 400 lines of code and simulation shows the same results.

BUG=393042

Review URL: https://codereview.chromium.org/387933005

[.stan]

Beta Channel now 64bit for Windows, too. http://www.google.com/intl/en/chrome/browser/beta.html

[Boo Berry]

Awesome, I finally dumped the 64-bit dev builds! :D

[Boo Berry]

Looks like they're messing with the continuous build directories... maybe they're in the process of fixing them?

[derkim]

 

:woot:

[Boo Berry]

Posting these here for others to follow:

 

https://code.google.com/p/chromium/issues/detail?id=384681

 

https://code.google.com/p/chromium/issues/detail?id=396140

 

Looks like they may of removed changelogs.

[+Zlip792 MVC]

Finally Chromium Snapshots changed from Git Hashes to SVN Number like before although changelogs has gone but no worries, I will rely on Git shortlogs.

 

EDIT: Huh!!! Its broken now: http://git.chromium.org/gitweb/?p=chromium.git;a=shortlog

 

Although this changelog does work: http://omahaproxy.appspot.com/ (Mentioned on last page by someone)

[Boo Berry]

Excellent, bookmark'd that site for changelogs. Now just waiting patiently for them to fix the Continuous builds.