Fix XHR's logic to determine whether or not to dispatch upload progress events

Fix XHR's logic to determine whether or not to dispatch upload progress events

Fix the m_uploadEventsAllowed variable (renamed by this commit to
m_uploadListenerFlag) to become true if and only if there're one or more
event handlers registered with the upload attribute.

Here's the background of the bug.

1. The m_uploadEventsAllowed variable has been introduced to
   XMLHttpRequest.cpp in
   http://crrev.com/405043c1ec2ad3dbb9ed711adc698c7d865923b6 to issue a
   preflight when there're one or more event handlers registered with
   the upload attribute even when the request is simple. This commit
   included one bug that the variable is set to true even when m_async
   is not set for same origin requests, but was correct in terms of
   handling of same/cross origin and simpleness of a request.
2. http://crrev.com/2c580376f830a33f06f2dd980c532e9e12498571 has
   mistakenly refactored the logic to set m_uploadEventsAllowed to true
   only when the request is not a simple request.
3. http://crrev.com/a5c5e927f63f72d121b62ddf6c1d9f093555e516 has fixed
   the bug partially by setting m_uploadEventsAllowed to true when the
   request is same origin.
4. http://crrev.com/03fac94860bfc63750af994932d3d38bd9335b3c has fixed
   the bug to set m_uploadEventsAllowed to true when there're one or
   more event handlers registered with the upload attribute as the spec
   says. But there're still unwanted variables left in the formula
   calculating m_uploadEventsAllowed, i.e. m_sameOriginRequest and the
   FetchUtils::isSimpleRequest() call.

m_uploadEventsAllowed and m_uploadComplete are renamed to make the
correspondence with the spec term clearer.

setReportUploadProgress() was called if and only if m_upload was not
NULL. But didSendData() was no-op (except for m_uploadComplete
updating but it's also used only for controlling handler invocation
on m_upload) when m_uploadEventAllowed is false. So, change the
condition to call setReportUnloadProgress() to be based on
m_uploadListenerFlag.

The only incompatibility this patch will introduce is that as long as
xhr.upload was touched before xhr.send() and the request is either
same origin or non-simple, we could set handlers to xhr.upload after
xhr.send() call to receive upload progress events. I think this
wouldn't have big impact.

This CL also removed m_httpBody from the condition. But this doesn't fix
the issue that the upload progress events are not dispatched when no
payload is given to send() call since didSendData() is not invoked
for zero length request body.

BUG=none

[tyoshino (SeeGerritForStatus), 2016-10-17 10:32:45]

Description was changed from

==========
Fix upload progress related flag logic

BUG=none
==========

to

==========
Fix upload progress related flag logic

Fix the m_uploadEventsAllowed variable (renamed by this commit to
m_uploadListenerFlag) to become true if and only if there're one or more
event handlers registered with the upload attribute.

Here's the background of the bug.

1. The m_uploadEventsAllowed variable has been introduced to
   XMLHttpRequest.cpp in
   http://crrev.com/405043c1ec2ad3dbb9ed711adc698c7d865923b6 to issue a
   preflight when there're one or more event handlers registered with
   the upload attribute even when the request is simple. This commit
   included one bug that the variable is set to true even when m_async
   is not set for same origin requests, but was correct in terms of
   handling of same/cross origin and simpleness of a request.
2. http://crrev.com/2c580376f830a33f06f2dd980c532e9e12498571 has
   mistakenly refactored the logic to set m_uploadEventsAllowed to true
   only when the request is not a simple request.
3. http://crrev.com/a5c5e927f63f72d121b62ddf6c1d9f093555e516 has fixed
   the bug partially by setting m_uploadEventsAllowed to true when the
   request is same origin.
4. http://crrev.com/03fac94860bfc63750af994932d3d38bd9335b3c has fixed
   the bug to set m_uploadEventsAllowed to true when there're one or
   more event handlers registered with the upload attribute as the spec
   says. But there're still unwanted variables left in the formula
   calculating m_uploadEventsAllowed, i.e. m_sameOriginRequest and the
   FetchUtils::isSimpleRequest() call.

m_uploadEventsAllowed and m_uploadComplete are renamed to make the
correspondence with the spec term clearer.

setReportUploadProgress() was called if and only if m_upload was not
NULL. But didSendData() was no-op (except for m_uploadComplete
updating but it's also used only for controlling handler invocation
on m_upload) when m_uploadEventAllowed is false. So, change the
condition to call setReportUnloadProgress() to be based on
m_uploadListenerFlag.

The only incompatibility this patch will introduce is that as long as
xhr.upload was touched before xhr.send() and the request is either
same origin or non-simple, we could set handlers to xhr.upload after
xhr.send() call to receive upload progress events. I think this
wouldn't have big impact.

This CL also removed httpBody from the condition.

BUG=none
==========

[tyoshino (SeeGerritForStatus), 2016-10-17 10:50:17]

Patchset #1 (id:1) has been deleted

[tyoshino (SeeGerritForStatus), 2016-10-17 10:50:54]

Description was changed from

==========
Fix upload progress related flag logic

Fix the m_uploadEventsAllowed variable (renamed by this commit to
m_uploadListenerFlag) to become true if and only if there're one or more
event handlers registered with the upload attribute.

Here's the background of the bug.

1. The m_uploadEventsAllowed variable has been introduced to
   XMLHttpRequest.cpp in
   http://crrev.com/405043c1ec2ad3dbb9ed711adc698c7d865923b6 to issue a
   preflight when there're one or more event handlers registered with
   the upload attribute even when the request is simple. This commit
   included one bug that the variable is set to true even when m_async
   is not set for same origin requests, but was correct in terms of
   handling of same/cross origin and simpleness of a request.
2. http://crrev.com/2c580376f830a33f06f2dd980c532e9e12498571 has
   mistakenly refactored the logic to set m_uploadEventsAllowed to true
   only when the request is not a simple request.
3. http://crrev.com/a5c5e927f63f72d121b62ddf6c1d9f093555e516 has fixed
   the bug partially by setting m_uploadEventsAllowed to true when the
   request is same origin.
4. http://crrev.com/03fac94860bfc63750af994932d3d38bd9335b3c has fixed
   the bug to set m_uploadEventsAllowed to true when there're one or
   more event handlers registered with the upload attribute as the spec
   says. But there're still unwanted variables left in the formula
   calculating m_uploadEventsAllowed, i.e. m_sameOriginRequest and the
   FetchUtils::isSimpleRequest() call.

m_uploadEventsAllowed and m_uploadComplete are renamed to make the
correspondence with the spec term clearer.

setReportUploadProgress() was called if and only if m_upload was not
NULL. But didSendData() was no-op (except for m_uploadComplete
updating but it's also used only for controlling handler invocation
on m_upload) when m_uploadEventAllowed is false. So, change the
condition to call setReportUnloadProgress() to be based on
m_uploadListenerFlag.

The only incompatibility this patch will introduce is that as long as
xhr.upload was touched before xhr.send() and the request is either
same origin or non-simple, we could set handlers to xhr.upload after
xhr.send() call to receive upload progress events. I think this
wouldn't have big impact.

This CL also removed httpBody from the condition.

BUG=none
==========

to

==========
Fix XHR's logic to determine whether or not to dispatch upload progress events

Fix the m_uploadEventsAllowed variable (renamed by this commit to
m_uploadListenerFlag) to become true if and only if there're one or more
event handlers registered with the upload attribute.

Here's the background of the bug.

1. The m_uploadEventsAllowed variable has been introduced to
   XMLHttpRequest.cpp in
   http://crrev.com/405043c1ec2ad3dbb9ed711adc698c7d865923b6 to issue a
   preflight when there're one or more event handlers registered with
   the upload attribute even when the request is simple. This commit
   included one bug that the variable is set to true even when m_async
   is not set for same origin requests, but was correct in terms of
   handling of same/cross origin and simpleness of a request.
2. http://crrev.com/2c580376f830a33f06f2dd980c532e9e12498571 has
   mistakenly refactored the logic to set m_uploadEventsAllowed to true
   only when the request is not a simple request.
3. http://crrev.com/a5c5e927f63f72d121b62ddf6c1d9f093555e516 has fixed
   the bug partially by setting m_uploadEventsAllowed to true when the
   request is same origin.
4. http://crrev.com/03fac94860bfc63750af994932d3d38bd9335b3c has fixed
   the bug to set m_uploadEventsAllowed to true when there're one or
   more event handlers registered with the upload attribute as the spec
   says. But there're still unwanted variables left in the formula
   calculating m_uploadEventsAllowed, i.e. m_sameOriginRequest and the
   FetchUtils::isSimpleRequest() call.

m_uploadEventsAllowed and m_uploadComplete are renamed to make the
correspondence with the spec term clearer.

setReportUploadProgress() was called if and only if m_upload was not
NULL. But didSendData() was no-op (except for m_uploadComplete
updating but it's also used only for controlling handler invocation
on m_upload) when m_uploadEventAllowed is false. So, change the
condition to call setReportUnloadProgress() to be based on
m_uploadListenerFlag.

The only incompatibility this patch will introduce is that as long as
xhr.upload was touched before xhr.send() and the request is either
same origin or non-simple, we could set handlers to xhr.upload after
xhr.send() call to receive upload progress events. I think this
wouldn't have big impact.

This CL also removed httpBody from the condition.

BUG=none
==========

[tyoshino (SeeGerritForStatus), 2016-10-17 10:51:07]

Description was changed from

==========
Fix XHR's logic to determine whether or not to dispatch upload progress events

Fix the m_uploadEventsAllowed variable (renamed by this commit to
m_uploadListenerFlag) to become true if and only if there're one or more
event handlers registered with the upload attribute.

Here's the background of the bug.

1. The m_uploadEventsAllowed variable has been introduced to
   XMLHttpRequest.cpp in
   http://crrev.com/405043c1ec2ad3dbb9ed711adc698c7d865923b6 to issue a
   preflight when there're one or more event handlers registered with
   the upload attribute even when the request is simple. This commit
   included one bug that the variable is set to true even when m_async
   is not set for same origin requests, but was correct in terms of
   handling of same/cross origin and simpleness of a request.
2. http://crrev.com/2c580376f830a33f06f2dd980c532e9e12498571 has
   mistakenly refactored the logic to set m_uploadEventsAllowed to true
   only when the request is not a simple request.
3. http://crrev.com/a5c5e927f63f72d121b62ddf6c1d9f093555e516 has fixed
   the bug partially by setting m_uploadEventsAllowed to true when the
   request is same origin.
4. http://crrev.com/03fac94860bfc63750af994932d3d38bd9335b3c has fixed
   the bug to set m_uploadEventsAllowed to true when there're one or
   more event handlers registered with the upload attribute as the spec
   says. But there're still unwanted variables left in the formula
   calculating m_uploadEventsAllowed, i.e. m_sameOriginRequest and the
   FetchUtils::isSimpleRequest() call.

m_uploadEventsAllowed and m_uploadComplete are renamed to make the
correspondence with the spec term clearer.

setReportUploadProgress() was called if and only if m_upload was not
NULL. But didSendData() was no-op (except for m_uploadComplete
updating but it's also used only for controlling handler invocation
on m_upload) when m_uploadEventAllowed is false. So, change the
condition to call setReportUnloadProgress() to be based on
m_uploadListenerFlag.

The only incompatibility this patch will introduce is that as long as
xhr.upload was touched before xhr.send() and the request is either
same origin or non-simple, we could set handlers to xhr.upload after
xhr.send() call to receive upload progress events. I think this
wouldn't have big impact.

This CL also removed httpBody from the condition.

BUG=none
==========

to

==========
Fix XHR's logic to determine whether or not to dispatch upload progress events

Fix the m_uploadEventsAllowed variable (renamed by this commit to
m_uploadListenerFlag) to become true if and only if there're one or more
event handlers registered with the upload attribute.

Here's the background of the bug.

1. The m_uploadEventsAllowed variable has been introduced to
   XMLHttpRequest.cpp in
   http://crrev.com/405043c1ec2ad3dbb9ed711adc698c7d865923b6 to issue a
   preflight when there're one or more event handlers registered with
   the upload attribute even when the request is simple. This commit
   included one bug that the variable is set to true even when m_async
   is not set for same origin requests, but was correct in terms of
   handling of same/cross origin and simpleness of a request.
2. http://crrev.com/2c580376f830a33f06f2dd980c532e9e12498571 has
   mistakenly refactored the logic to set m_uploadEventsAllowed to true
   only when the request is not a simple request.
3. http://crrev.com/a5c5e927f63f72d121b62ddf6c1d9f093555e516 has fixed
   the bug partially by setting m_uploadEventsAllowed to true when the
   request is same origin.
4. http://crrev.com/03fac94860bfc63750af994932d3d38bd9335b3c has fixed
   the bug to set m_uploadEventsAllowed to true when there're one or
   more event handlers registered with the upload attribute as the spec
   says. But there're still unwanted variables left in the formula
   calculating m_uploadEventsAllowed, i.e. m_sameOriginRequest and the
   FetchUtils::isSimpleRequest() call.

m_uploadEventsAllowed and m_uploadComplete are renamed to make the
correspondence with the spec term clearer.

setReportUploadProgress() was called if and only if m_upload was not
NULL. But didSendData() was no-op (except for m_uploadComplete
updating but it's also used only for controlling handler invocation
on m_upload) when m_uploadEventAllowed is false. So, change the
condition to call setReportUnloadProgress() to be based on
m_uploadListenerFlag.

The only incompatibility this patch will introduce is that as long as
xhr.upload was touched before xhr.send() and the request is either
same origin or non-simple, we could set handlers to xhr.upload after
xhr.send() call to receive upload progress events. I think this
wouldn't have big impact.

This CL also removed httpBody from the condition.

BUG=none
==========

[tyoshino (SeeGerritForStatus), 2016-10-17 10:51:12]

The CQ bit was checked by tyoshino@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-17 10:51:29]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-17 12:23:32]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-17 12:23:33]

Dry run: This issue passed the CQ dry run.

[tyoshino (SeeGerritForStatus), 2016-10-19 08:58:57]

Description was changed from

==========
Fix XHR's logic to determine whether or not to dispatch upload progress events

Fix the m_uploadEventsAllowed variable (renamed by this commit to
m_uploadListenerFlag) to become true if and only if there're one or more
event handlers registered with the upload attribute.

Here's the background of the bug.

1. The m_uploadEventsAllowed variable has been introduced to
   XMLHttpRequest.cpp in
   http://crrev.com/405043c1ec2ad3dbb9ed711adc698c7d865923b6 to issue a
   preflight when there're one or more event handlers registered with
   the upload attribute even when the request is simple. This commit
   included one bug that the variable is set to true even when m_async
   is not set for same origin requests, but was correct in terms of
   handling of same/cross origin and simpleness of a request.
2. http://crrev.com/2c580376f830a33f06f2dd980c532e9e12498571 has
   mistakenly refactored the logic to set m_uploadEventsAllowed to true
   only when the request is not a simple request.
3. http://crrev.com/a5c5e927f63f72d121b62ddf6c1d9f093555e516 has fixed
   the bug partially by setting m_uploadEventsAllowed to true when the
   request is same origin.
4. http://crrev.com/03fac94860bfc63750af994932d3d38bd9335b3c has fixed
   the bug to set m_uploadEventsAllowed to true when there're one or
   more event handlers registered with the upload attribute as the spec
   says. But there're still unwanted variables left in the formula
   calculating m_uploadEventsAllowed, i.e. m_sameOriginRequest and the
   FetchUtils::isSimpleRequest() call.

m_uploadEventsAllowed and m_uploadComplete are renamed to make the
correspondence with the spec term clearer.

setReportUploadProgress() was called if and only if m_upload was not
NULL. But didSendData() was no-op (except for m_uploadComplete
updating but it's also used only for controlling handler invocation
on m_upload) when m_uploadEventAllowed is false. So, change the
condition to call setReportUnloadProgress() to be based on
m_uploadListenerFlag.

The only incompatibility this patch will introduce is that as long as
xhr.upload was touched before xhr.send() and the request is either
same origin or non-simple, we could set handlers to xhr.upload after
xhr.send() call to receive upload progress events. I think this
wouldn't have big impact.

This CL also removed httpBody from the condition.

BUG=none
==========

to

==========
Fix XHR's logic to determine whether or not to dispatch upload progress events

Fix the m_uploadEventsAllowed variable (renamed by this commit to
m_uploadListenerFlag) to become true if and only if there're one or more
event handlers registered with the upload attribute.

Here's the background of the bug.

1. The m_uploadEventsAllowed variable has been introduced to
   XMLHttpRequest.cpp in
   http://crrev.com/405043c1ec2ad3dbb9ed711adc698c7d865923b6 to issue a
   preflight when there're one or more event handlers registered with
   the upload attribute even when the request is simple. This commit
   included one bug that the variable is set to true even when m_async
   is not set for same origin requests, but was correct in terms of
   handling of same/cross origin and simpleness of a request.
2. http://crrev.com/2c580376f830a33f06f2dd980c532e9e12498571 has
   mistakenly refactored the logic to set m_uploadEventsAllowed to true
   only when the request is not a simple request.
3. http://crrev.com/a5c5e927f63f72d121b62ddf6c1d9f093555e516 has fixed
   the bug partially by setting m_uploadEventsAllowed to true when the
   request is same origin.
4. http://crrev.com/03fac94860bfc63750af994932d3d38bd9335b3c has fixed
   the bug to set m_uploadEventsAllowed to true when there're one or
   more event handlers registered with the upload attribute as the spec
   says. But there're still unwanted variables left in the formula
   calculating m_uploadEventsAllowed, i.e. m_sameOriginRequest and the
   FetchUtils::isSimpleRequest() call.

m_uploadEventsAllowed and m_uploadComplete are renamed to make the
correspondence with the spec term clearer.

setReportUploadProgress() was called if and only if m_upload was not
NULL. But didSendData() was no-op (except for m_uploadComplete
updating but it's also used only for controlling handler invocation
on m_upload) when m_uploadEventAllowed is false. So, change the
condition to call setReportUnloadProgress() to be based on
m_uploadListenerFlag.

The only incompatibility this patch will introduce is that as long as
xhr.upload was touched before xhr.send() and the request is either
same origin or non-simple, we could set handlers to xhr.upload after
xhr.send() call to receive upload progress events. I think this
wouldn't have big impact.

This CL also removed m_httpBody from the condition. But this doesn't fix
the issue that the upload progress events are not dispatched when no
payload is given to send() call since didSendData() is not invoked
for zero length request body.

BUG=none
==========

[tyoshino (SeeGerritForStatus), 2016-10-19 08:59:39]

The CQ bit was checked by tyoshino@chromium.org to run a CQ dry run

[tyoshino (SeeGerritForStatus), 2016-10-19 08:59:49]

Description was changed from

==========
Fix XHR's logic to determine whether or not to dispatch upload progress events

Fix the m_uploadEventsAllowed variable (renamed by this commit to
m_uploadListenerFlag) to become true if and only if there're one or more
event handlers registered with the upload attribute.

Here's the background of the bug.

1. The m_uploadEventsAllowed variable has been introduced to
   XMLHttpRequest.cpp in
   http://crrev.com/405043c1ec2ad3dbb9ed711adc698c7d865923b6 to issue a
   preflight when there're one or more event handlers registered with
   the upload attribute even when the request is simple. This commit
   included one bug that the variable is set to true even when m_async
   is not set for same origin requests, but was correct in terms of
   handling of same/cross origin and simpleness of a request.
2. http://crrev.com/2c580376f830a33f06f2dd980c532e9e12498571 has
   mistakenly refactored the logic to set m_uploadEventsAllowed to true
   only when the request is not a simple request.
3. http://crrev.com/a5c5e927f63f72d121b62ddf6c1d9f093555e516 has fixed
   the bug partially by setting m_uploadEventsAllowed to true when the
   request is same origin.
4. http://crrev.com/03fac94860bfc63750af994932d3d38bd9335b3c has fixed
   the bug to set m_uploadEventsAllowed to true when there're one or
   more event handlers registered with the upload attribute as the spec
   says. But there're still unwanted variables left in the formula
   calculating m_uploadEventsAllowed, i.e. m_sameOriginRequest and the
   FetchUtils::isSimpleRequest() call.

m_uploadEventsAllowed and m_uploadComplete are renamed to make the
correspondence with the spec term clearer.

setReportUploadProgress() was called if and only if m_upload was not
NULL. But didSendData() was no-op (except for m_uploadComplete
updating but it's also used only for controlling handler invocation
on m_upload) when m_uploadEventAllowed is false. So, change the
condition to call setReportUnloadProgress() to be based on
m_uploadListenerFlag.

The only incompatibility this patch will introduce is that as long as
xhr.upload was touched before xhr.send() and the request is either
same origin or non-simple, we could set handlers to xhr.upload after
xhr.send() call to receive upload progress events. I think this
wouldn't have big impact.

This CL also removed m_httpBody from the condition. But this doesn't fix
the issue that the upload progress events are not dispatched when no
payload is given to send() call since didSendData() is not invoked
for zero length request body.

BUG=none
==========

to

==========
Fix XHR's logic to determine whether or not to dispatch upload progress events

Fix the m_uploadEventsAllowed variable (renamed by this commit to
m_uploadListenerFlag) to become true if and only if there're one or more
event handlers registered with the upload attribute.

Here's the background of the bug.

1. The m_uploadEventsAllowed variable has been introduced to
   XMLHttpRequest.cpp in
   http://crrev.com/405043c1ec2ad3dbb9ed711adc698c7d865923b6 to issue a
   preflight when there're one or more event handlers registered with
   the upload attribute even when the request is simple. This commit
   included one bug that the variable is set to true even when m_async
   is not set for same origin requests, but was correct in terms of
   handling of same/cross origin and simpleness of a request.
2. http://crrev.com/2c580376f830a33f06f2dd980c532e9e12498571 has
   mistakenly refactored the logic to set m_uploadEventsAllowed to true
   only when the request is not a simple request.
3. http://crrev.com/a5c5e927f63f72d121b62ddf6c1d9f093555e516 has fixed
   the bug partially by setting m_uploadEventsAllowed to true when the
   request is same origin.
4. http://crrev.com/03fac94860bfc63750af994932d3d38bd9335b3c has fixed
   the bug to set m_uploadEventsAllowed to true when there're one or
   more event handlers registered with the upload attribute as the spec
   says. But there're still unwanted variables left in the formula
   calculating m_uploadEventsAllowed, i.e. m_sameOriginRequest and the
   FetchUtils::isSimpleRequest() call.

m_uploadEventsAllowed and m_uploadComplete are renamed to make the
correspondence with the spec term clearer.

setReportUploadProgress() was called if and only if m_upload was not
NULL. But didSendData() was no-op (except for m_uploadComplete
updating but it's also used only for controlling handler invocation
on m_upload) when m_uploadEventAllowed is false. So, change the
condition to call setReportUnloadProgress() to be based on
m_uploadListenerFlag.

The only incompatibility this patch will introduce is that as long as
xhr.upload was touched before xhr.send() and the request is either
same origin or non-simple, we could set handlers to xhr.upload after
xhr.send() call to receive upload progress events. I think this
wouldn't have big impact.

This CL also removed m_httpBody from the condition. But this doesn't fix
the issue that the upload progress events are not dispatched when no
payload is given to send() call since didSendData() is not invoked
for zero length request body.

BUG=none
==========

[tyoshino (SeeGerritForStatus), 2016-10-19 08:59:49]

tyoshino@chromium.org changed reviewers:
+ yhirano@chromium.org

[tyoshino (SeeGerritForStatus), 2016-10-19 09:01:41]

Found while checking dependency to SecurityOrigin in XMLHttpRequest.cpp.

[commit-bot: I haz the power, 2016-10-19 09:31:05]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-19 12:21:19]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-19 12:21:20]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[yhirano, 2016-10-20 11:27:54]

description: "setReportUnloadProgress" should be "setReportUploadProgress".

https://codereview.chromium.org/2427553002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequest.cpp (right):

https://codereview.chromium.org/2427553002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequest.cpp:943:
m_uploadListenerFlag = false;
In the spec this flag is initialized in open function. How about moving the
statement to there?

https://codereview.chromium.org/2427553002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequest.cpp:1249:
m_uploadCompleteFlag = true;
Is substituting unconditionally enough?

https://codereview.chromium.org/2427553002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequest.cpp:1649: //
TODO(tyoshino): Since AsyncResourceHandler doesn't send us any
"Since" is not needed?

https://codereview.chromium.org/2427553002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequest.cpp:1662: return;
This statement is redundant.

[yhirano, 2016-10-20 12:17:02]

https://codereview.chromium.org/2427553002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequest.cpp (right):

https://codereview.chromium.org/2427553002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequest.cpp:1639:
DCHECK(m_async);
You call setReportUploadProgress only when m_uploadListenerFlag is set. Can we
have DCHECK(m_uploadListenerFlag)?

https://codereview.chromium.org/2427553002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequest.cpp:1648: 
Not related to this CL but we may need an early-return here for the case where
open and/or send are called in the progress handler.