New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 4 link

Starred by 204 users

Comments by non-members will not trigger notification emails to users who starred this issue.

Issue metadata

Status: Fixed
Owner:
Email to this user bounced
Closed: Oct 2008
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Restricted
  • Only users with Commit permission may comment.


Show other hotlists

Hotlists containing this issue:
test-group-edit-acl


Sign in to add a comment

Scrolling with some scroll mice (touchpad, etc.) scrolls down but not up

Reported by thijs...@gmail.com, Sep 2 2008

Issue description

Product Version      : <see about:version>
URLs (if applicable) :0.2.149.27
Other browsers tested: Firefox / IE
Add OK or FAIL after other browsers where you have tested this issue:
Safari 3:
    Firefox 3: OK
         IE 7:OK

What steps will reproduce the problem?
1. Open any webpage on compaq 6715s running vista.
2. Try scrolling with the touchpad
3. Scrolling down will work , but up will not.

What is the expected result?
The page to scroll up.

What happens instead?
The page doesn't move.

Please provide any additional information below. Attach a screenshot if 
possible.
Only a minor bug.
 
Showing comments 221 - 320 of 320 Older
Confirmed on HP Pavilion dv6233se running 32-bit XP Pro SP3 w/ Synaptics TouchPad 
v6.3 running driver v11.1.21.0
I can confirm this on my Acer Extensa 5420. It goes down, but not up. It only happens 
in Google Chrome, no other applications have this problem. 

I have Synaptics PS/2 Port TouchPad driver version 9.0.1.0 and I'm running Windows 
Vista Ultimate 32-bit SP1.

Comment 223 by Deleted ...@, Sep 8 2008

Confirmed on a HP dv5 1060 with vista premium x32

Comment 224 by Deleted ...@, Sep 8 2008

Same problem on an Acer Aspire One, running xp sp3
Confirmed on a Acer Extensa 5620Z, running Windos Vista Home Premium
-- PLEASE STOP POSTING "CONFIRMATIONS" OR "I ALSO SEE THIS" OR "+1"'s --
-- PLEASE STOP POSTING "CONFIRMATIONS" OR "I ALSO SEE THIS" OR "+1"'s --
-- PLEASE STOP POSTING "CONFIRMATIONS" OR "I ALSO SEE THIS" OR "+1"'s --
-- PLEASE STOP POSTING "CONFIRMATIONS" OR "I ALSO SEE THIS" OR "+1"'s --
-- PLEASE STOP POSTING "CONFIRMATIONS" OR "I ALSO SEE THIS" OR "+1"'s --

Just star it. WE KNOW IT DOSNT WORK!!!
I just wish you would stop telling people to stop it. It's not about the fact that
they _know_ it doesn't work. It's about narrowing the issue to where and why it's
happening. The only way to do that is to let them know what it doesn't work with.
It dosnt work that way. We know now that its comfirmed. You can just star it. As of 
now, we know their is a bug and its been assigned. So sit tight and wait for a fix. 
No need to further tell us that their is a bug. We KNOW

Comment 229 by Deleted ...@, Sep 8 2008

Confirmed on Toshiba A135-S4527 using Synaptics touch pad.

If using a mouse with scroll wheel it works fine.


Information like people are posting here is helpful for developers, like mmihajlovic
said it helps developers narrow down the bug.
Confirmed on Dell/Intel Core 2 Duo.
Dell mouse model R41108
Using WinXP SP2 with "Dell Mouse Suite" installed.  Mouse suite allows for scroll 
speed, which seems to affect the downward scroll speed (too fast actually), but 
upward is always at zero.
Tried it on several HP laptops running windows XP, all have the same problem.

Comment 232 by Deleted ...@, Sep 8 2008

Confirmed on Acer 5611 awlmi using Synaptics touch pad.
Confirmed issue on HP Pavilion dv6835nr, Synaptics touch pad.
Windows Vista Home Premium.
Also confirmed on XP SP2 and XP SP3 on Acer Travelmate 8200 (8204) with Synaptics 
touch pad.
Confirmed comment 42 on Vista Home Premium 32-bit.

Comment 236 by aju...@gmail.com, Sep 9 2008

Mr affan do you know if they identified the exact problem and do u have any idea when 
the fix will be available.
Is there any laptop / touchpad with which scrolling does work?

Comment 238 by Deleted ...@, Sep 9 2008

> Is there any laptop / touchpad with which scrolling does work?

Yes, laptops with alps touchpads... but scrolling is a bit fast.
So the issue is with Synaptics driver+GC (And possibly others)?
(Scrolling is wrong on a regular desktop too)

http://spreadsheets.google.com/pub?key=piEywtesotIPC4Q7mScNUWA&output=html


>>
>> Is there any laptop / touchpad with which scrolling does work?
>
> Yes, laptops with alps touchpads... but scrolling is a bit fast.
>

Comment 241 by Deleted ...@, Sep 9 2008

I'm not sure about this, as my laptop has been sent off for repair and I can't test 
the theory, also I'm not a windows programmer. 

I think the synaptic drivers don't use the standard windows scroll wheel interface, 
but instead send scrolling events directly to the window, this allows the driver to 
chose between sending the events to the active window or the window under the wheel 
which windows doesn't natively support.
Confirmed on HP/Compaq 6910p, Synaptics Touchpad v6.2 (on PS/2 port 3), Synaptics 
driver version 10.0.13.2, Windows XP SP2
If anyone else with this problem has Dell Mouse Suite running, try closing it.  That 
fixed this bug for me.
signal to noise ratio approaching zero here - how about someone closing this bug and opening a new one with 
explicit directions in the bug to NOT POST +1's etc.  

otherwise, well, i hate to say it but all these blatantly annoying people make me want this bug to never be fixed 
- i want it to annoy them forever.  i feel like i'm reading the comments to a slashdot post about religion.  -bleh-
@Ajundi: No, I am not sure when this will be fixed. I have a feeling that there might
be a update release from Synaptics to fix their driver issue IF that is the case as
PhireN points out.

Comment 246 by Deleted ...@, Sep 10 2008

Confirmed on HP Compaq nc6220. Scroll down works and scroll up does not works :(
Some quotes:
"The only way to do that is to let them know what it doesn't work with."
[...]
"Information like people are posting here is helpful for developers, like mmihajlovic
said it helps developers narrow down the bug."

I agree, but there is a limit! Do you really think any developer is going to read 
200+ post with every computer configuration possible to narrow the bug? That is just 
not true, I can know: I am a developer.

People just annoy the rest of the people who starred the bug and is working 
CONTRAPRODUCTIVE. Real important messages are being flood by people like above. 
I just disabled email all together, got tired of the massive amount of spam this bug 
generated.

SO PLEASE STOP POSTING COMMENTS UNTIL A DEVELOPER IS ASKING FOR MORE INPUT OR YOU 
HAVE SOMETHING _REALLY_ INTERESTING TO MENTION!

Comment 248 by iam...@gmail.com, Sep 11 2008

What he said.

Comment 249 by Deleted ...@, Sep 11 2008

Downward scrolling not working on Asus g50v A-1.

Comment 250 by Deleted ...@, Sep 11 2008

also cannot scroll up on an acer extensa 5420

Comment 251 by a51...@gmail.com, Sep 11 2008

Works fine on a Vaio Laptop. The only issue is the touchpad scrolls too much per 
scroll.

Comment 252 by bwa...@gmail.com, Sep 11 2008

I'm sorry but these spam post saying

-- PLEASE STOP POSTING "CONFIRMATIONS" OR "I ALSO SEE THIS" OR "+1"'s --
-- PLEASE STOP POSTING "CONFIRMATIONS" OR "I ALSO SEE THIS" OR "+1"'s --

are the MOST counterproductive at all, follow your own advice and post something
useful or don't post at all.

Comment 253 by affa...@gmail.com, Sep 12 2008

^so you basically just contradicted your self. It is useful. I have starred this to 
show that this issue needs to be taken care of. 

If you have any idea whats wrong, or can provide a code snippet, or debug the 
problem, by all means reply. but replying with useless comments (which the developer 
obviously does not need) is a waste of my time and email space.

Comment 254 by mkte...@gmail.com, Sep 12 2008

I am testing on Windows XP with:
- A plug-and-play USB mouse, listed as "HID-compliant mouse" in Device Manager, with
Microsoft driver version 5.1.2600.0.
- My touchpad, listed as "Alps Pointing-device for VAIO", with Alps driver version
5.3.511.2.

With the USB mouse, if the Windows mouse-scroll setting is "One screen at a time" (my
preferred setting), it only scrolls one *line* at a time, and the scroll directions
are inverted.  (i.e., up is down and down is up.)  If I change the Windows setting to
"scroll N lines at a time" (where N is a number), it works correctly.

With the touchpad, if the Windows setting is "One screen at a time", it doesn't
respond at all.  If I change to "N lines at a time", it responds, but it scrolls N
times the distance the USB mouse does on the same setting.

Comment 255 by mazo...@gmail.com, Sep 12 2008

Confirmed: Win XP - SP 3
The scroll up never works on synaptic touchpad

Comment 256 by Deleted ...@, Sep 12 2008

windows vista. synaptic touchpad. scroll up does not work  on side scroll of 
touchpad.
Confirmed on a HP Pavillion dv9000 running vista ultimate.

Comment 258 by cpu...@gmail.com, Sep 13 2008

Synaptics Touchpad Edgemotion panel scan scroll down, but not up
Confirmed on Vista SP1 with several HP Pavilion notebooks

Comment 259 by sum...@gmail.com, Sep 13 2008

Same with HP Laptop Touchpad + Windows XP. Scroll down is OK but not going up.
Confirmed with HP Pavillion dv2000 running vista home primium....
scrolling only downwords. scroll up does not work  on side scroll of 
touchpad.(synaptic touchpad)

Comment 261 by Deleted ...@, Sep 13 2008

Same issue on HP Pavillion dv9628nr running Windows Vista. Can only scroll down using 
touch pad but NOT up!

Comment 262 by Deleted ...@, Sep 13 2008

Confirmed on an Acer Aspire One running Windows XP Home SP3. Touchpad scrolls down 
but not up.

Is there a way to up the priority on this? Seems to me like this is a pretty big 
deal; Laptop users' browsing experience are seriously hindered by this bug.

Comment 263 by Deleted ...@, Sep 14 2008

Confirmed with HP Compaq 6820s

Comment 264 by Deleted ...@, Sep 14 2008

Confirmed on Toshiba Satellite A105-S4001 windows xp home. Touchpad scrolls down but 
not up.

Comment 265 by sum...@gmail.com, Sep 15 2008

:)))))
Just do this in this blog's software:(pseudo)

if Assigned(case):
   while(posts.end):
      if post.find('confirm') > 0 Then
         DiscardPost(post)
      else:
         # added for more robustness
         if post.find('+1'):
            DiscardPost(post)

You should be pleased, I have not seen any customer like this. Someone even gave
his/her graphic card model:)))
Labels: intext
b/1368021
We know this is a bug and a fix is in the works 
(http://codereview.chromium.org/2878). 

I'm going to mark this read only to prevent further confirmation and 'me too' 
messages. 
Status: Fixed
I still have this problem , scrolling does not work up or down on most web pages.
The exception is the history results page of chrome itself , where the the pointer 
jumps to the scroll bar moves up or down as required and then jumps back to the web 
page. I have the synaptics touchpad. 

Comment 270 by jmh...@gmail.com, Oct 19 2008

@joseph.f.brennan:

This problem has been fixed for Dev Channel releases and has been for the last 2 Dev 
Channel releases.  The problem will probably be fixed in the next standard Chrome 
release, which I unfortunately have no idea of a date for when it will happen.
am i right in assuming that when it is included in a standard release that this topic
will post notification?

Comment 272 by jmh...@gmail.com, Oct 20 2008

Yes, I am pretty sure this will be updated and in some way closed once it is included 
in the standard release.

Comment 273 by affa...@gmail.com, Oct 20 2008

Hi does anyone know how i can get the latest code? I am new with SVN and stuff so I 
am also looking for a tutorial as well.

Thanks

Comment 274 by jmh...@gmail.com, Oct 20 2008

I have not been doing anything with the actual code, but I do know that if you click 
the Tools button (the wrench) in Chrome and click "About Google Chrome" it will check 
for and install the latest build of Google Chrome.  Also, somewhere there is a 
download for chromechannel-1.0 which will change you from the standard Chrome channel 
to the Dev Channel if you want, which receives updates earlier and more frequently 
(ie. we already have the fix for this bug).

App to update to the latest Dev builds as they are released:
http://chromium.googlecode.com/files/chromechannel-1.0.exe

I have done this, and it is working fine. No issues as far as I can see.

Google Chrome: 0.3.154.3 (Official Build 3339)
WebKit: 525.19
V8: 0.3.4.1
User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19
(KHTML, like Gecko) Chrome/0.3.154.3 Safari/525.19

Comment 276 by jmh...@gmail.com, Oct 20 2008

Yes, that is the latest Dev build.  http://googlechromereleases.blogspot.com

Comment 277 by Deleted ...@, Oct 24 2008

it is still not fixed.... i m facing this from the first day... this sucks.. :(
works fine on 0.3.155.0
I never tried a Chromium release or the dev-channel releases. A clean install of 0.3.154.9 and I see the problem is fixed. (WinXP x64)
Fixed in 0.3.154.9 noticed it this morning.(HP 6510b)
Thank you!

Comment 281 by nim...@gmail.com, Nov 6 2008

As reported by my brother : scrolling issue NOT fixed by 0.3.154.9 :(

He tells he tried different mouse drivers without success. He adds : how is it that 
no app (other than Chrome) has problems with wheel scrolling ? (Me: maybe is Chrome 
multi-platform and using diverse pieces of open source not optimised for/correctly 
tested on Windows ?)

Please look into this issue very seriously lest Chrome's inadequacy to address real 
problems became a joke. (Yes there are many problems with the rendering engine too)

Regards

-- 
Czerno

Comment 282 by Deleted ...@, Nov 6 2008

@nimbux

The synaptic drivers do scrolling in a unconventional way, and other apps do have
problems.

However synaptic releases driver updates to work around the problems when they
happen, but they haven't had time to release a fixed driver for chrome yet.

Comment 283 by nim...@gmail.com, Nov 6 2008

@282 (PhireN) : I'll be gathering /full/ details (hardware, OS and drivers  
versions...)  & report. Postponing answer till then. Thanks for your reply though. 
Fixed for me in 0.3.154.9 . I have an Asus U6E with the Synaptic touchpad. For those 
of you who haven't seen it fixed yet, make sure to manually go to the About window 
and check for updates. That is how I got mine fixed. Thanks Google!
nimbux:

It'd help if we can get information about the hardware and software installed so that 
we can try it out in-house to reproduce it and make a fix.

Also, please note that sometimes Chrome needs to be restarted in order for the update 
(to the latest version) take effect. 

Comment 286 by nim...@gmail.com, Nov 6 2008

Amit, my brother just answered my query : 


- Windows XP SP3 OS. 
- His mouse is IBM (Lenovo) model "MO3280"
- drivers, according to Windows driver mgmt app : mousclas.sys et mouhid.sys
- version 5.1.260.2180

- symptom : wheel scrolling down, not up.

I'll have him restart and check for Chrome's reported version number and more precise
machine details (it's a desktop comp, not a portable). Unfortunately won't be until
tomorrow, please stay tuned !





Comment 287 by nim...@gmail.com, Nov 7 2008

So, his Chrome is confirmed up to date (0.3.154.9)
Mouse drivers (HID) mouseclas.sys 5.1.2600.5512(xpsp.080413-2108) and 
mouhid.sys 5.1.2600.1(XPClient.010817-1148)

The machine itself is an unspecified ACER desktop with AMD 64-dual core processor.

HTH...


Comment 288 by nim...@gmail.com, Nov 8 2008

Last minute... *** RESOLVED **** 

The mouse still had to be unhooked from the USB, then hooked on again. Scrolling both 
up and down now, works as designed  :=)

Does the above reported voodoo make any sense, considering the machine had been 
rebooted several time without repairing the problem ? 

Case closed anyway as far as we're concerned, and hopefully for all the others too !


Comment 289 by Deleted ...@, Nov 14 2008

Lenovo HID mouse, has the same problem, can't scroll up!

Comment 290 by nim...@gmail.com, Nov 19 2008

Is there a regression bug with this issue again ? After updating to the latest
0.4.154.22 (dev channel)... Brother's USB mouse won't scroll up  :-(

This time unplugging/replugging it does NOT cure the problem.

I respectfully suggest a complete top-down (or would it be bottom up ?)
reexamination/rework of the mouse scrolling in Chrome under Windows !

Sometimes redoing things from scratch has not been a loss of time in my (old) experience.

Regards


-- 
NimbUx
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=9953 

------------------------------------------------------------------------
r9953 | idanan@chromium.org | 2009-02-18 10:55:46 -0800 (Wed, 18 Feb 2009) | 2 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/tabs/tab.cc?r1=9953&r2=9952
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/tabs/tab.h?r1=9953&r2=9952
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/tabs/tab_strip.cc?r1=9953&r2=9952
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/tabs/tab_strip.h?r1=9953&r2=9952
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/custom_frame_window.cc?r1=9953&r2=9952
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/custom_frame_window.h?r1=9953&r2=9952
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/event.h?r1=9953&r2=9952
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/root_view.cc?r1=9953&r2=9952
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/view.cc?r1=9953&r2=9952
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/widget_win.cc?r1=9953&r2=9952
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/widget_win.h?r1=9953&r2=9952

Solved 2 bugs which caused Chrome to maximize itself whendouble clicking, either on the new tab button, on the closetab button or on a single tab.BUG=2827BUG=3787The problem comes from the Windows event sequence upon adouble-click (simplified here):1 - hit-test2 - mouse-down4 - mouse-up/click5 - hit-test6 - mouse down7 - mouse up/double-clickThe 1st hit-test is always performed correctly, returningclient for tabs and non-client for the tab-strip (background).The 2nd hit test is not performed correctly to avoid crashesin Chromebot from events being processed while tabs are animating.Since we have no record of these crashes, Ben prefers we keepthis special-case, even though we are responding incorrectlyto the windows hit-test. So, when the tabs are animating wereturn a HTNOWHERE hit which the caller translates into anHTCAPTION hit. This even though a tab-control (new-tab/close-tab)may have been hit.The problem is that having returned HTCAPTION to Windows defaultmessage handling, we get a NON-CLIENT double-click event insteadof a standard one.To keep the behavior of the second hit-test AND prevent theChrome window from maximizing, this change simply declaresthe non-client double-click as handled when the tabs areanimating.Another trick we pulled in the hit-test is to return HTCAPTIONwhen a single tab is present. This allows the entire window to be dragged but causes the context menu to be wrong and the windowto maximize when double clicking on the single tab.The solution here is to correct return a client hit for a singletab and, upon handling a client single-click, delegate to thenon-client single-click default handler.
Review URL: http://codereview.chromium.org/21268
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=21203 

------------------------------------------------------------------------
r21203 | estade@chromium.org | 2009-07-21 12:51:24 -0700 (Tue, 21 Jul 2009) | 100 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/render_widget_host_view_gtk.cc?r1=21203&r2=21202
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/render_widget_host_view_gtk.h?r1=21203&r2=21202
   M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/api/src/gtk/WebInputEventFactory.cpp?r1=21203&r2=21202

This change list improves IME support on Linux. Many corner cases that were not
handled in original code are addressed, for example the input method in password
box case.

The most important change in this CL is the change to key event processing flow.
 In old code, a key event will first be sent to webkit then dispatched to IME
for filtering. With this CL, a key event will first be dispatched to IME for
filtering, then how to send the event to webkit is decided by the filtering
result.

This CL tries to emulate the keyboard input behavior on Windows as much as
possible. For example, if a keydown event is filtered by IME, then its virtual
key code will be changed to VK_PROCESSKEY(0xE5) to prevent webkit from
processing it again. This behavior can workaround  bug 16281 .

To test this CL, you may cut and save following html code into a file and open
it in chrome.
------------------8<----cut here----->8---------------------
<html><head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">

<script>
function keyEventHandler(event) {
  var props = [ "type", "charCode", "keyCode", "altKey",
    "ctrlKey", "shiftKey", "metaKey" ];
  var info = document.getElementById('info');
  var s = '';
  for (var i in props) {
    s += props[i] + ':' + event[props[i]] + ' ';
  }
  info.value += s + '\n';
}

function textEventHandler(event) {
  info.value += "type:" + event['type'] + " data:" + event['data'] + '\n';
}

function passwordChangeEventHandler(event) {
  var input2 = document.getElementById('input2');
  info.value += "password:" + input2.value + '\n';
}

function onLoad() {
  var input = document.getElementById('input');
  input.addEventListener('keydown', keyEventHandler, false);
  input.addEventListener('keyup', keyEventHandler, false);
  input.addEventListener('keypress', keyEventHandler, false);
  input.addEventListener('textInput', textEventHandler, false);
  var input2 = document.getElementById('input2');
  input2.addEventListener('change', passwordChangeEventHandler, false);
}
</script>
</head><body onload="onLoad()">
<input id="input" size="20">
<input id="input2" type="password" size="20">
<p>
<textarea id="info" rows="40" cols="150"></textarea>
</p></body></html>
------------------8<----cut here----->8---------------------

This CL was confirmed to fix following issues:
BUG= 16281  "arrow keys and backspace/delete keys move/delete two characters at a
time when xim immodule is used"
BUG= 16282  "Disable IMEs in a password input"
BUG= 16596  "fcitx (chinese input method) not working in ubuntu 9.04"
BUG= 16659  "Crash near RenderWidgetHostViewGtk::IMEUpdateStatus"
BUG= 16699  "Can't move cursor to omnibox and use input method if cursor is
currently in a text input box in web page."
BUG= 16796  "Input method issue: When inputting text in a text box, if there is a
composition string then pressing Backspace or Delete will cause the composition
string be cleared and the text box refuses to accept any further input.

All tests assume above html code is used.
TEST=Start scim with "scim -d" and start chrome with GTK_IM_MODULE=xim and
XMODIFIERS=@im=SCIM. Type something in input box, eg. "hello", then press
backspace, to see if only one character is deleted.
TEST=Move cursor to password input box, press ctrl-space to see if input method
is not activated. Switch keyboard layout to Canadian-French then type a'[{' key
and an 'a' key, then press enter, to see if a Latin character "U+00E2" is
inputted in password box.
TEST=Install fcitx with "sudo apt-get install fcitx" (assume you are using
Ubuntu/Debian). Open a terminal, export XMODIFIERS=@im=fcitx and
GTK_IM_MODULE=xim then run fcitx, then start chrome. Move cursor into an input
box, press ctrl-space and input something, eg. "nihao" then press space. Check
if some Chinese characters are inputted.
TEST=Start chrome with GTK_IM_MODULE=scim. Move cursor into a text input box
then move into a password box, chrome should not crash.
TEST=Move cursor into a text input box, then click omnibox, and see if the text
input box has lost focus. Press ctrl-space to activate input method, then type
something, and see of the input goes into omnibox.
TEST=Move cursor into a text input box and enable a Chinese Pinyin input method,
then type something, eg. "dajiahao", make sure a composition string is displayed
in the text input box, then press backspace and see if there is still a
composition string and backspace is handled by input method.

patch by James Su <james.su [at] gmail>
original review URL: <http://codereview.chromium.org/149755>


Review URL: http://codereview.chromium.org/155869
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=29749 

------------------------------------------------------------------------
r29749 | mark@chromium.org | 2009-10-21 18:47:49 -0700 (Wed, 21 Oct 2009) | 42 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_pump_mac.h?r1=29749&r2=29748
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_pump_mac.mm?r1=29749&r2=29748

Change the strategy used to attempt nesting-deferred work to account equally
well for nested run loops under our own control (those started by Run) and
those beyond our control (native event loops).

Previously, upon any exit from a nested native loop, we would schedule
nesting-deferred work for processing.  However, some nested native loops do
not execute in a single loop; rather, they start and stop the CFRunLoop
rapidly.  In such cases, each exit from the CFRunLoop would cause
nesting-deferred work to be scheduled, and on each new entry to the CFRunLoop,
we would attempt to process it.  This rapid-fire action meant that we'd never
sleep.  Nested loops managed by Run were exempt from these problems since
r28811, because we could defer scheduling nesting-deferred work until
returning to Run.

The new strategy is to detect whether any nested loops (native or managed by
Run) had run before the run loop goes to sleep or exits.  If any nested loops
did run, nesting-deferred work is scheduled for processing.

BUG= 24968 
TEST=1. Test case from  bug 24968 , printing: open any page, press command-P,
        leave the dialog up, and check Chrome's CPU usage.  No Chrome process
        should be monopolizing any CPU.  This tests nested native run loops.
     2. Test case from  bug 24337 , JS alerts: open Gmail, start composing a new
        message in a new window, address it to yourself, move focus to the
        subject field, click the Discard button, and click "OK" at the alert.
        The alert and composition window should close.
     3. Test case from  bug 24383 , JS alerts: no Chrome processes should use
        100% CPU after visiting javascript:alert("hi").  The JS alert cases
        test nested run loops managed by Run.
     4. Test case from  bug 13468  comment 5, autocomplete: autocomplete should
        still work after using "Back" from a contextual menu.  This tests
        that nesting-deferred work is processed after leaving a nested run
        loop.
     5. First run UI test case (no bug).  Remove or move aside the profile
        directory (~/Library/Application Support/Chromium or
        ~/Library/Application Support/Google/Chrome) and launch the
        application.  There should be first-run UI and it should be usable.
        Upon clicking "Start (application)", the application should start and
        be usable as normal.  This tests delegateless run loops and
        delegateless work redispatch.
     6. base_unittests --gtest_filter='MessageLoopTest.*'
Review URL: http://codereview.chromium.org/300044
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=32640 

------------------------------------------------------------------------
r32640 | jshin@chromium.org | 2009-11-20 11:24:35 -0800 (Fri, 20 Nov 2009) | 12 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/linux/icudt42l_dat.s?r1=32640&r2=32639
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/mac/icudt42l_dat.s?r1=32640&r2=32639
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/patches/data.build.patch?r1=32640&r2=32639
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/patches/segmentation.patch.txt?r1=32640&r2=32639

Remove invuca.icu table from the ICU data file again. It was added to make Chrome not crash with a webkit patch for
 bug 30437  (https://bugs.webkit.org/show_bug.cgi?id=30437)

However, the webkit patch was rolled back so that we don't need invuca.icu for now. Removing it will cut down the data size by 230k (before compression and in the Chrome executable on Linux/Mac and the ICU data dll on Linux).
This has to be added back when it becomes necessary again to fix the aforementioned webkit bug. 

See also  http://crbug.com/28132  (a bug about ~ 4kB of space wasted by copyright statements) 

BUG= 20406 
TEST=NONE

Review URL: http://codereview.chromium.org/399089
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=32651 

------------------------------------------------------------------------
r32651 | jshin@chromium.org | 2009-11-20 12:01:15 -0800 (Fri, 20 Nov 2009) | 16 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/icudt42.dll?r1=32651&r2=32650
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/source/data/in/icudt42l.dat?r1=32651&r2=32650

Remove invuca.icu table from the ICU data file again (part 2 : Windows. For part 1, see http://codereview.chromium.org/399089/show)

It was added to make Chrome not crash with a webkit patch for 
 bug 30437  (https://bugs.webkit.org/show_bug.cgi?id=30437) 

However, the webkit patch was rolled back so that we don't need invuca.icu for now. Removing it will cut down the data size by 230k (before compression and in the Chrome executable on Linux/Mac and the ICU data dll on Linux). 
This has to be added back when it becomes necessary again to fix the aforementioned webkit bug. 

See also  http://crbug.com/28132  (a bug about ~ 4kB of space wasted by copyright statements) 

TBR=evan
BUG= 20406 
TEST=NONE 


Review URL: http://codereview.chromium.org/418018
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=33118 

------------------------------------------------------------------------
r33118 | jshin@chromium.org | 2009-11-25 13:22:20 -0800 (Wed, 25 Nov 2009) | 16 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/DEPS?r1=33118&r2=33117

Pull in icu@32651:

Remove invuca.icu table from the ICU data file again(see http://codereview.chromium.org/399089/show)

It was added to make Chrome not crash with a webkit patch for 
 bug 30437  (https://bugs.webkit.org/show_bug.cgi?id=30437) 

However, the webkit patch was rolled back so that we don't need invuca.icu for now. Removing it will cut down the data size by 230k (before compression and in the Chrome executable on Linux/Mac and the ICU data dll on Linux). 
This has to be added back when it becomes necessary again to fix the aforementioned webkit bug. 

See also  http://crbug.com/28132  (a bug about ~ 4kB of space wasted by copyright statements)

BUG= 20406 
TEST=All the webkit tests pass.

Review URL: http://codereview.chromium.org/418019
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=33157 

------------------------------------------------------------------------
r33157 | jshin@chromium.org | 2009-11-25 15:47:28 -0800 (Wed, 25 Nov 2009) | 19 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/249/src/DEPS?r1=33157&r2=33156

Merge 33118 - Pull in icu@32651:

Remove invuca.icu table from the ICU data file again(see http://codereview.chromium.org/399089/show)

It was added to make Chrome not crash with a webkit patch for 
 bug 30437  (https://bugs.webkit.org/show_bug.cgi?id=30437) 

However, the webkit patch was rolled back so that we don't need invuca.icu for now. Removing it will cut down the data size by 230k (before compression and in the Chrome executable on Linux/Mac and the ICU data dll on Linux). 
This has to be added back when it becomes necessary again to fix the aforementioned webkit bug. 

See also  http://crbug.com/28132  (a bug about ~ 4kB of space wasted by copyright statements)

BUG= 20406 
TEST=All the webkit tests pass.

Review URL: http://codereview.chromium.org/418019

TBR=jshin@chromium.org
Review URL: http://codereview.chromium.org/434104
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=32640 

------------------------------------------------------------------------
r32640 | jshin@chromium.org | 2009-11-20 11:24:35 -0800 (Fri, 20 Nov 2009) | 12 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/linux/icudt42l_dat.s?r1=32640&r2=32639
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/mac/icudt42l_dat.s?r1=32640&r2=32639
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/patches/data.build.patch?r1=32640&r2=32639
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/patches/segmentation.patch.txt?r1=32640&r2=32639

Remove invuca.icu table from the ICU data file again. It was added to make Chrome not crash with a webkit patch for
 bug 30437  (https://bugs.webkit.org/show_bug.cgi?id=30437)

However, the webkit patch was rolled back so that we don't need invuca.icu for now. Removing it will cut down the data size by 230k (before compression and in the Chrome executable on Linux/Mac and the ICU data dll on Linux).
This has to be added back when it becomes necessary again to fix the aforementioned webkit bug. 

See also  http://crbug.com/28132  (a bug about ~ 4kB of space wasted by copyright statements) 

BUG= 20406 
TEST=NONE

Review URL: http://codereview.chromium.org/399089
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=32651 

------------------------------------------------------------------------
r32651 | jshin@chromium.org | 2009-11-20 12:01:15 -0800 (Fri, 20 Nov 2009) | 16 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/icudt42.dll?r1=32651&r2=32650
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/source/data/in/icudt42l.dat?r1=32651&r2=32650

Remove invuca.icu table from the ICU data file again (part 2 : Windows. For part 1, see http://codereview.chromium.org/399089/show)

It was added to make Chrome not crash with a webkit patch for 
 bug 30437  (https://bugs.webkit.org/show_bug.cgi?id=30437) 

However, the webkit patch was rolled back so that we don't need invuca.icu for now. Removing it will cut down the data size by 230k (before compression and in the Chrome executable on Linux/Mac and the ICU data dll on Linux). 
This has to be added back when it becomes necessary again to fix the aforementioned webkit bug. 

See also  http://crbug.com/28132  (a bug about ~ 4kB of space wasted by copyright statements) 

TBR=evan
BUG= 20406 
TEST=NONE 


Review URL: http://codereview.chromium.org/418018
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=34440 

------------------------------------------------------------------------
r34440 | oshima@chromium.org | 2009-12-12 19:07:36 -0800 (Sat, 12 Dec 2009) | 3 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/valgrind/unit_tests.gtest_mac.txt?r1=34440&r2=34439

4th attemp to make valgrind/mac happy. see  bug 30209 .

TBR: viettrungluu@chromium.org
------------------------------------------------------------------------

Comment 301 by ilci...@gmail.com, Jun 11 2010

still having this issue,'Up & Down' Scrolling doesn't work with a Tosbiba Portege M300  XP Pro SP3 - Synaptics 6.2 - Chrome 5.0 

Comment 302 by kenorb@gmail.com, Oct 27 2010

lol, the oldest bug:)

Is there a solution to scroll bug on chrome with synaptic touch pad. Google Chrome SUCKS!!!!
This bug reappeared in latest dev version (9.0.597.15 dev) with Logitech V550 mouse on Ubuntu Linux.
After upgrading to  dev version 9.0.597.15 I have this problem with Microsoft Standard Wireless Optical Mouse on Windows XP SP3.

Comment 306 by Deleted ...@, Dec 25 2010

Can't scroll at all using Synaptics touchpad with their latest drivers and Chrome (8.0.552.224) avail. Laptop - Compaq Presario 2500, OS is Windows XP, SP3. Scrolling with other applications and Internet Explorer works.
Project Member

Comment 307 by bugdroid1@chromium.org, May 20 2011

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=86171

------------------------------------------------------------------------
r86171 | mrossetti@chromium.org | Fri May 20 16:29:12 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/autocomplete/history_quick_provider.cc?r1=86171&r2=86170&pathrev=86171
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/autocomplete/history_quick_provider_unittest.cc?r1=86171&r2=86170&pathrev=86171

Fix Wrong Offset

Set content offset using fill_into_edit's length and not the length of the originally typed term.

BUG= 82994 
TEST=Added unit test. Manual test: 1) Delete the 'History Provider Cache' file, 2) Start Chrome, 3) Type 'about:flags' into omnibox and <ret>, 4) Type 'about:flags/' or 'about:flags@' into omnibox. There should no longer be an assert at this point.
Review URL: http://codereview.chromium.org/7004042
------------------------------------------------------------------------
Project Member

Comment 308 by bugdroid1@chromium.org, Jun 12 2011

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=88800

------------------------------------------------------------------------
r88800 | xiyuan@chromium.org | Sun Jun 12 16:27:12 PDT 2011

Changed paths:
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/chromeos/upgrade_detector_chromeos.cc?r1=88800&r2=88799&pathrev=88800
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/chromeos/upgrade_detector_chromeos.h?r1=88800&r2=88799&pathrev=88800
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_browser.gypi?r1=88800&r2=88799&pathrev=88800
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/upgrade_detector_impl.h?r1=88800&r2=88799&pathrev=88800
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/upgrade_detector.h?r1=88800&r2=88799&pathrev=88800
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/upgrade_detector.cc?r1=88800&r2=88799&pathrev=88800
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/upgrade_detector_impl.cc?r1=88800&r2=88799&pathrev=88800 (from /trunk/src/chrome/browser/upgrade_detector.cc revision 88799)

Refactor UpgradeDetector.

- Move peroidically timer based detection code into UpgradeDetectorImpl
  for use on non-ChromeOS platform;
- Implement ChromeOS upgrade detection via UpdateLibrary observer and
  apply a slightly different advisory timing for showing the badges
  (show green arrow immediately on upgrade detected, then 2, 4, 7 days
  for yellow, red and orange color);

BUG=chromium-os:16146
TEST=Verify fix for chromium-os:16146.

Review URL: http://codereview.chromium.org/7046096
------------------------------------------------------------------------
Project Member

Comment 309 by bugdroid1@chromium.org, Jun 12 2011

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=88801

------------------------------------------------------------------------
r88801 | xiyuan@chromium.org | Sun Jun 12 16:32:00 PDT 2011

Changed paths:
 A http://src.chromium.org/viewvc/chrome/branches/782/src/chrome/browser/chromeos/upgrade_detector_chromeos.h?r1=88801&r2=88800&pathrev=88801 (from /trunk/src/chrome/browser/chromeos/upgrade_detector_chromeos.h revision 88800)
 M http://src.chromium.org/viewvc/chrome/branches/782/src/chrome/browser/upgrade_detector.cc?r1=88801&r2=88800&pathrev=88801
 M http://src.chromium.org/viewvc/chrome/branches/782/src/chrome/browser/upgrade_detector.h?r1=88801&r2=88800&pathrev=88801
 A http://src.chromium.org/viewvc/chrome/branches/782/src/chrome/browser/chromeos/upgrade_detector_chromeos.cc?r1=88801&r2=88800&pathrev=88801 (from /trunk/src/chrome/browser/chromeos/upgrade_detector_chromeos.cc revision 88800)
 M http://src.chromium.org/viewvc/chrome/branches/782/src/chrome/chrome_browser.gypi?r1=88801&r2=88800&pathrev=88801
 A http://src.chromium.org/viewvc/chrome/branches/782/src/chrome/browser/upgrade_detector_impl.cc?r1=88801&r2=88800&pathrev=88801 (from /trunk/src/chrome/browser/upgrade_detector_impl.cc revision 88800)
 A http://src.chromium.org/viewvc/chrome/branches/782/src/chrome/browser/upgrade_detector_impl.h?r1=88801&r2=88800&pathrev=88801 (from /trunk/src/chrome/browser/upgrade_detector_impl.h revision 88800)

Merge 88800 - Refactor UpgradeDetector.

- Move peroidically timer based detection code into UpgradeDetectorImpl
  for use on non-ChromeOS platform;
- Implement ChromeOS upgrade detection via UpdateLibrary observer and
  apply a slightly different advisory timing for showing the badges
  (show green arrow immediately on upgrade detected, then 2, 4, 7 days
  for yellow, red and orange color);

BUG=chromium-os:16146
TEST=Verify fix for chromium-os:16146.

Review URL: http://codereview.chromium.org/7046096

TBR=davemoore@chromium.org
Review URL: http://codereview.chromium.org/7129071
------------------------------------------------------------------------
Project Member

Comment 310 by bugdroid1@chromium.org, Oct 27 2011

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=107553

------------------------------------------------------------------------
r107553 | glider@chromium.org | Thu Oct 27 03:08:38 PDT 2011

Changed paths:
 A http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/clang/3.1/include/.dir?r1=107553&r2=107552&pathrev=107553
 A http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/clang/3.1/include/emmintrin.h?r1=107553&r2=107552&pathrev=107553
 A http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/clang/3.1/include/stdbool.h?r1=107553&r2=107552&pathrev=107553
 A http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/clang/3.1/include/mmintrin.h?r1=107553&r2=107552&pathrev=107553
 M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/README.chromium?r1=107553&r2=107552&pathrev=107553
 A http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/clang/3.1/include/immintrin.h?r1=107553&r2=107552&pathrev=107553
 A http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/clang/3.1/include/stdint.h?r1=107553&r2=107552&pathrev=107553
 A http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/clang/3.1/include?r1=107553&r2=107552&pathrev=107553
 A http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/clang/3.1/include/nmmintrin.h?r1=107553&r2=107552&pathrev=107553
 M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/bin/clang?r1=107553&r2=107552&pathrev=107553
 A http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/clang/3.1/include/pmmintrin.h?r1=107553&r2=107552&pathrev=107553
 M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/libasan64.a?r1=107553&r2=107552&pathrev=107553
 A http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/clang/3.1/include/smmintrin.h?r1=107553&r2=107552&pathrev=107553
 A http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/clang/3.1/include/float.h?r1=107553&r2=107552&pathrev=107553
 A http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/clang/3.1/include/tmmintrin.h?r1=107553&r2=107552&pathrev=107553
 A http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/clang/3.1/include/wmmintrin.h?r1=107553&r2=107552&pathrev=107553
 A http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/clang/3.1/include/xmmintrin.h?r1=107553&r2=107552&pathrev=107553
 A http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/clang/3.1/include/tgmath.h?r1=107553&r2=107552&pathrev=107553
 A http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/clang/3.1/include/mm_malloc.h?r1=107553&r2=107552&pathrev=107553
 A http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/clang/3.1/include/stdalign.h?r1=107553&r2=107552&pathrev=107553
 A http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/clang/3.1/include/stddef.h?r1=107553&r2=107552&pathrev=107553
 A http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/clang/3.1/include/avxintrin.h?r1=107553&r2=107552&pathrev=107553
 A http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/clang/3.1/include/altivec.h?r1=107553&r2=107552&pathrev=107553
 A http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/clang/3.1/include/stdarg.h?r1=107553&r2=107552&pathrev=107553
 A http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/clang/3.1/include/iso646.h?r1=107553&r2=107552&pathrev=107553
 M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/libasan32.a?r1=107553&r2=107552&pathrev=107553
 D http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/clang/3.0?r1=107553&r2=107552&pathrev=107553
 A http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/clang/3.1?r1=107553&r2=107552&pathrev=107553
 A http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/clang/3.1/include/x86intrin.h?r1=107553&r2=107552&pathrev=107553
 A http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/clang/3.1/include/limits.h?r1=107553&r2=107552&pathrev=107553
 A http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/clang/3.1/include/arm_neon.h?r1=107553&r2=107552&pathrev=107553
 A http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/clang/3.1/include/varargs.h?r1=107553&r2=107552&pathrev=107553
 A http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/asan/asan_clang_Linux/lib/clang/3.1/include/mm3dnow.h?r1=107553&r2=107552&pathrev=107553

New ASan binaries for Linux (r946)

Now with str* interceptors and __asan_report_{load,store}{1,2,4,8}!

TBR=kcc
Review URL: http://codereview.chromium.org/8404033
------------------------------------------------------------------------
Project Member

Comment 311 by bugdroid1@chromium.org, Nov 1 2011

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=108074

------------------------------------------------------------------------
r108074 | rsleevi@chromium.org | Mon Oct 31 22:13:21 PDT 2011

Changed paths:
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/data/ssl/certificates/weak_digest_sha1_root.pem?r1=108074&r2=108073&pathrev=108074
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/data/ssl/certificates/weak_digest_md5_ee.pem?r1=108074&r2=108073&pathrev=108074
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/data/ssl/certificates/weak_digest_md4_ee.pem?r1=108074&r2=108073&pathrev=108074
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/data/ssl/certificates/weak_digest_md5_root.pem?r1=108074&r2=108073&pathrev=108074
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/data/ssl/certificates/weak_digest_md2_ee.pem?r1=108074&r2=108073&pathrev=108074
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/data/ssl/certificates/weak_digest_md4_root.pem?r1=108074&r2=108073&pathrev=108074
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/data/ssl/certificates/weak_digest_md2_root.pem?r1=108074&r2=108073&pathrev=108074
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/data/ssl/certificates/weak_digest_sha1_intermediate.pem?r1=108074&r2=108073&pathrev=108074
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/data/ssl/certificates/weak_digest_md5_intermediate.pem?r1=108074&r2=108073&pathrev=108074
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/data/ssl/certificates/weak_digest_md4_intermediate.pem?r1=108074&r2=108073&pathrev=108074
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/data/ssl/certificates/weak_digest_md2_intermediate.pem?r1=108074&r2=108073&pathrev=108074
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/x509_certificate_unittest.cc?r1=108074&r2=108073&pathrev=108074
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/data/ssl/certificates/weak_digest_sha1_ee.pem?r1=108074&r2=108073&pathrev=108074

Add unittests for the detection of md[2,4,5] when verifying certificates

BUG= 101123 
TEST=net_unittests:X509CertificateWeakDigestTest.*


Review URL: http://codereview.chromium.org/8391036
------------------------------------------------------------------------
Project Member

Comment 312 by bugdroid1@chromium.org, Nov 2 2011

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=108308

------------------------------------------------------------------------
r108308 | rsleevi@chromium.org | Wed Nov 02 10:09:25 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/x509_certificate_mac.cc?r1=108308&r2=108307&pathrev=108308
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/x509_certificate_win.cc?r1=108308&r2=108307&pathrev=108308
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/x509_certificate_unittest.cc?r1=108308&r2=108307&pathrev=108308

Record when certificates signed with md[2,4,5] are encountered on OS X.

R=wtc@chromium.org
BUG= 101123 



Review URL: http://codereview.chromium.org/8374019
------------------------------------------------------------------------
Project Member

Comment 313 by bugdroid1@chromium.org, Nov 3 2011

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=108425

------------------------------------------------------------------------
r108425 | rsleevi@chromium.org | Wed Nov 02 20:44:29 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/x509_certificate_openssl.cc?r1=108425&r2=108424&pathrev=108425
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/x509_certificate_unittest.cc?r1=108425&r2=108424&pathrev=108425

Record when certificates signed with md[2,4,5] are encountered when using OpenSSL

R=joth@chromium.org
BUG= 101123 



Review URL: http://codereview.chromium.org/8368015
------------------------------------------------------------------------
Project Member

Comment 314 by bugdroid1@chromium.org, Mar 8 2012

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=125645

------------------------------------------------------------------------
r125645 | satorux@chromium.org | Thu Mar 08 10:46:49 PST 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/chromeos/extensions/file_browser_private_api.cc?r1=125645&r2=125644&pathrev=125645
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/resources/file_manager/js/file_manager.js?r1=125645&r2=125644&pathrev=125645

gdata: First cut at adding support for uploading from gdata.

Known issue 1: the file name shown in the web page, and used for
uploading is human-unreadable and wrong (as of now, it looks like
".org.chromium.Chromium.CtC9KF").
crosbug.com/27222

Known  issue 2 : the downloading progress is not shown in the UI.
crosbug.com/27504

Known  issue 3 : downloading cannot be canceled.
crosbug.com/27505

Known  issue 4 : the downloaded file is not deleted. The issue is
gone once the cache layer in GDataFileSystem is in place.
crosbug.com/26910

BUG=chromium-os:27244
TEST=manually

Review URL: https://chromiumcodereview.appspot.com/9640001
------------------------------------------------------------------------
Project Member

Comment 315 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 316 by bugdroid1@chromium.org, Mar 11 2013

Labels: -Area-WebKit Cr-Content
Project Member

Comment 317 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content Cr-Blink
Blocking: chromium:263848
Blocking: -chromium:263848
Issue 431203 has been merged into this issue.
Showing comments 221 - 320 of 320 Older

Sign in to add a comment