Bug Triaging for WebKit (release 0.1 for DPS911)

For the 0.1 release for WebKit, I decided to start with one small but important thing. My professor David Humphrey suggested me to start from some bug triaging. After looking trough the WebKit’s Bugzilla with David, we found out the following bug:

https://bugs.webkit.org/show_bug.cgi?id=53586#c2
https://bugs.webkit.org/show_bug.cgi?id=53586#c2

Bug states that Safari and Chrome have errors with rounding the sizes in cm (yes, Chrome was running the WebKit engine in 2011, please see my previous blog post for more details about the history of WebKit):

It appears webkit is rounding sizes specified in "cm" down, where other browsers are not…

As well bug contains the necessary code for reproducing itself:

<!doctype html>
<script>
 for (var i = 0; i < 5; i++) {
 var iSize = Math.pow(10, i);
 var o = document.createElement('span');
 document.documentElement.appendChild(o);
 o.style.display = 'block';
 o.style.width = iSize + 'cm';
 document.write('1cm = ' + (o.clientWidth / iSize) + 'px +/- ~0.' + new Array(i).join('0') + '5<br/>');
 }
</script>

But after running this code in Safari, Firefox, Chrome, and Opera in February 2019 I actually got the following results for different browsers:

All of the browsers output the same and correct results! All the values are the same for all 4 browsers, which means that the bug was fixed!

But we wanted to understand how it was fixed. After researching the implementation of “roundForImpreciseConversion” function in Source/WebCore/css/CSSPrimitiveValue.h file on the unofficial mirror of WebKit we found out the following code:

template<typename T> inline T roundForImpreciseConversion(double value)
{
 // Dimension calculations are imprecise, often resulting in values of e.g.
 // 44.99998. We need to go ahead and round if we're really close to the
 // next integer value.
 value += (value < 0) ? -0.01 : +0.01;
 return ((value > std::numeric_limits<T>::max()) || (value < std::numeric_limits<T>::min())) ? 0 : static_cast<T>(value);
}

I believe that after the following Sanders Shen’s (weizhengshen@gmail.com) fix/edit on 24 Feb 2012:

return ((value > max) || (value < min)) ? 0 : static_cast<T>(lround(value));

macpherson@chromium.org did the final fix/edit to “return” function code to fix this bug on 20 Mar 2012:

return ((value > std::numeric_limits<T>::max()) || (value < std::numeric_limits<T>::min())) ? 0 : static_cast<T>(value);
final edit by macpherson@chromium.org on Mar 20, 2012

All of that means that this bug is no longer a bug! Because any of those 4 browsers do not have any rounding errors. As well we can’t talk about WebKit bugs anymore in the context of Chrome (desktop version) and Opera, because in April 2013, Google and Opera Software announced the transition to the Blink engine. WebKit powers a Google Chrome only on the iOS version of the browser.

After understanding that this is no longer a bug and researching how it was fixed I wrote a comment on Bugzilla.

Working on this bug helped me to understand WebKit’s repo more, because looking through the codes of WebKit as well as knowing the history of browser engines helped me actually understand how this bug was fixed and why this is no longer a bug. Right now I am waiting for responses from WebKit community about my comment.