Don't use rowIndex() if needsCellRecalc().

The row index may be bogus or even unset in that case.

Rows may be inserted with an initially unknown row index. This happens
when the row isn't inserted at the end of its table section, and also
when splitting an anonymous row. This would lead to an assertion failure
for row()->rowIndexWasSet() in RenderTableCell::styleDidChange().
rowIndex() is used there in a call to
RenderTableSection::rowLogicalHeightChanged(). rowIndex() is also used
in a similar way in RenderTableRow::styleDidChange(), albeit without
asserting first.

styleDidChange() may be called while needsCellRecalc() is set, which
may mean that row index hasn't been calculated yet (or is bogus). We
could of course just recalculate the cells (which also involves
calculating all row indices) in styleDidChange(), but it's not really
necessary, since the row index was just needed in order to call
rowLogicalHeightChanged(), which just bails anyway if cells need recalc.

So the solution is to pass a RenderTableRow instead of the row index to
rowLogicalHeightChanged(). This way we don't call rowIndex() when
row index is unknown.

BUG=397442

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

git-svn-id: svn://svn.chromium.org/blink/trunk@181637 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Oilpan: Fix ASan instrumentation around heap object headers.

We poison the heap object headers because only our code should ever be
able to access them and only from a handful of methods. Poisoning the
headers lets us catch stray read/writes that end up in our headers and we
use the NO_SANITIZE_ADDRESS annotation on the handful of methods that
operate on the headers.

The ASan NO_SANITIZE_ADDRESS annotation does not propagate to acquireLoad.
Our first attempt to fix that was to unpoison the address accessed.
However, that does not work because we are using this code from multiple
threads without locking (which is the reason for using atomic ops).
Therefore, the threads will have races when it comes to poisoning.

This change fixes the issue by introducing asan aware
asanAcquireLoad/asanReleaseStore which will work on poisoned memory
when you know what you are doing.

Kostya, do you have any alternative suggestions?

R=erik.corry@gmail.com, kcc@chromium.org, oilpan-reviews@chromium.org, zerny@chromium.org
BUG=411712

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

git-svn-id: svn://svn.chromium.org/blink/trunk@181638 bbb929c8-8fbe-4397-9dbb-9b2b20218538
DevTools: [Documentation] fix css styles for renderer

BUG=391593

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

git-svn-id: svn://svn.chromium.org/blink/trunk@181639 bbb929c8-8fbe-4397-9dbb-9b2b20218538