Created attachment 234791[details]
Archive of layout-test-results from webkit-ews-14 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-14 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5
Created attachment 234793[details]
Archive of layout-test-results from webkit-ews-01 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-01 Port: mac-mountainlion Platform: Mac OS X 10.8.5
Created attachment 234794[details]
Archive of layout-test-results from webkit-ews-02 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-02 Port: mac-mountainlion Platform: Mac OS X 10.8.5
Comment on attachment 234798[details]
Patch
I did not get the time to do a review today :(
I like that you are removing EAlignItems. I am not sure I like the name ItemPosition to replace it...
But honestly, given it touches code outside CSS GRID, I would prefer if this patch waited 1-2 weeks so that it does not land in the middle of a Safari-WebKit branch.
(In reply to comment #9)
> But honestly, given it touches code outside CSS GRID, I would prefer if this patch waited 1-2 weeks so that it does not land in the middle of a Safari-WebKit branch.
I am told we just have to wait until the end of this week to avoid messing with the branches.
(In reply to comment #10)
> (In reply to comment #9)
> > But honestly, given it touches code outside CSS GRID, I would prefer if this patch waited 1-2 weeks so that it does not land in the middle of a Safari-WebKit branch.
>
> I am told we just have to wait until the end of this week to avoid messing with the branches.
Sure, no problem. I still have other patches related to alignment and justification to work on.
Thanks anyway.
Created attachment 235786[details]
Archive of layout-test-results from webkit-ews-08 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-08 Port: mac-mountainlion Platform: Mac OS X 10.8.5
Created attachment 235793[details]
Archive of layout-test-results from webkit-ews-06 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-06 Port: mac-mountainlion Platform: Mac OS X 10.8.5
Created attachment 235798[details]
Archive of layout-test-results from webkit-ews-13 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-13 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5
Created attachment 235803[details]
Archive of layout-test-results from webkit-ews-14 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-14 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5
Comment on attachment 235775[details]
Patch
View in context: https://bugs.webkit.org/attachment.cgi?id=235775&action=review
I only had a quick look :(
Some comments:
> Source/WebCore/css/CSSComputedStyleDeclaration.cpp:1650
> +static ItemPosition resolveAlignmentAuto(ItemPosition position, Node* element)
> +{
> + if (position != ItemPositionAuto || !element || !element->computedStyle())
> + return position;
> +
> + return element->computedStyle()->isDisplayFlexibleOrGridBox() ? ItemPositionStretch : ItemPositionStart;
> +}
I don't understand this little dance with the computed style. You are using this from ComputedStyleExtractor, you should not get the style directly from the element, you take the style as an argument from the ComputedStyleExtractor.
The one taking the parent node is another problem, in that case you need to test "element" and "element->computedStyle()".
> Source/WebCore/css/CSSComputedStyleDeclaration.cpp:1657
> + result->append(CSSPrimitiveValue::create(itemPosition));
> + if (itemPosition >= ItemPositionCenter && overflowAlignment != OverflowAlignmentDefault)
> + result->append(CSSPrimitiveValue::create(overflowAlignment));
Why is this code avoiding the Value Pool?
> Source/WebCore/css/CSSParser.cpp:3085
> +static bool isBaselinePositionKeyword(CSSValueID id)
static inline
> Source/WebCore/rendering/RenderFlexibleBox.cpp:1305
> + // FIXME: File a bug about implementing that. The extended grammar
> + // is not enabled by default so we shouldn't hit this codepath.
File the bug, put the bugzilla number here :)
> Source/WebCore/rendering/style/RenderStyle.h:1583
> +
Blank line.
It seems that my approach of resolving the "auto" values during the CSS Cascade have some limitations, which caused some mathhml layout tests to fail.
This is the Box Aligment specification I'm following in my mplementation:
- http://dev.w3.org/csswg/css-align-3/
The root cause of these failires is that mathml layout code changes the value of the alignItems property on several renders. I expected that to force a style recalculation, as it happens when properties are changed through javascript. This is controlled by the WebCore::Style::determineChange, which now it forces a Dettach whenever the change affects to the alignItems property.
The intention of my patch was to avoid logic duplication of this "auto" resolution, since both grid an flex share the same logic. Also, the CSScomputedStyleDeclaration needs to implement exactly the same logic. Besides, now, according to the last specs, the default value of all the properties is "auto", so when resolving the "alignSelf", it's not enough to refer to the parent's alignItem; this has to be resolved too.
To complicate things even more, there is now a "legacy" keyword that forces the "justifyItems" property to be inherited by all the descendants. All this logic seems to be naturally implemented in the css cascade, which also would simplify the resolution implemented by the renders.
However, there are several issues on this approach; first of all, the anonymous renderers are not part of the css cascade resolution. Also, several renders derive from RenderFelxibleBoxm but they don't specify the appropriated display value, which is what the css cascade use to discriminate between different elements. Finally, changes in the alignItem performed in the layout phase should trigger, somehow, a style recalc at least in the subtree.
Created attachment 235908[details]
Archive of layout-test-results from webkit-ews-15 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-15 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5
Created attachment 235915[details]
Archive of layout-test-results from webkit-ews-01 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-01 Port: mac-mountainlion Platform: Mac OS X 10.8.5
Created attachment 235926[details]
Archive of layout-test-results from webkit-ews-14 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-14 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5
Created attachment 235927[details]
Archive of layout-test-results from webkit-ews-03 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-03 Port: mac-mountainlion Platform: Mac OS X 10.8.5
Created attachment 235928[details]
Archive of layout-test-results from webkit-ews-16 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-16 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5
Created attachment 236928[details]
Archive of layout-test-results from webkit-ews-08 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-08 Port: mac-mountainlion Platform: Mac OS X 10.8.5
Created attachment 236929[details]
Archive of layout-test-results from webkit-ews-11 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-11 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5
Created attachment 236930[details]
Archive of layout-test-results from webkit-ews-04 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-04 Port: mac-mountainlion Platform: Mac OS X 10.8.5
Created attachment 237085[details]
Archive of layout-test-results from webkit-ews-11 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-11 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5
Created attachment 237088[details]
Archive of layout-test-results from webkit-ews-01 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-01 Port: mac-mountainlion Platform: Mac OS X 10.8.5
Created attachment 237091[details]
Archive of layout-test-results from webkit-ews-05 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-05 Port: mac-mountainlion Platform: Mac OS X 10.8.5
For some reason, I still don't fully understand (I have some ideas, though) my patch triggers the issue described in the bug #136291. That's why my first patches caused the platform/mac/accessibility/webkit-alt-for-css-content.html test to fail.
I've filled that bug to track the issue and make this dependent of it; I'll do the same with the mathml related test failing. My last patch provides fixes for both tests, but I think separated bugs for them are more convenient.
(In reply to comment #51)
> For some reason, I still don't fully understand (I have some ideas, though)
> my patch triggers the issue described in the bug #136291. That's why my
> first patches caused the
> platform/mac/accessibility/webkit-alt-for-css-content.html test to fail.
>
> I've filled that bug to track the issue and make this dependent of it; I'll
> do the same with the mathml related test failing. My last patch provides
> fixes for both tests, but I think separated bugs for them are more
> convenient.
Filed bug #138095 to track the MathML issue, which will be noticeable once this patch lands.
Comment on attachment 240511[details]
Patch
View in context: https://bugs.webkit.org/attachment.cgi?id=240511&action=review
I don't think I should r+. I would like Dave Hyatt to have a look.
> Source/WebCore/rendering/RenderFlexibleBox.cpp:1275
> + // FIXME: https://webkit.org/b/135460 - The extended grammar is not supported
> + // yet for FlexibleBox.
> + // Defaulting to Stretch for now, as it what most of FlexBox based renders
> + // expect as default.
I would add notImplemented() here.
> Source/WebCore/rendering/RenderFlexibleBox.cpp:1309
> + // FIXME: https://webkit.org/b/135460 - The extended grammar is not supported
> + // yet for FlexibleBox.
ditto
> Source/WebCore/style/StyleResolveTree.cpp:125
> + if (s1->alignItems() != s2->alignItems())
Wait, what?
How did that not break tests?
Comment on attachment 240511[details]
Patch
Looks fine. I'm not really a fan of "ItemPosition" though. It just sounds too generic. I don't have a better suggestion though, so I guess r+.
Created attachment 241547[details]
Archive of layout-test-results from webkit-ews-15 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-15 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5
Created attachment 241560[details]
Archive of layout-test-results from webkit-ews-05 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-05 Port: mac-mountainlion Platform: Mac OS X 10.8.5
Created attachment 241596[details]
Archive of layout-test-results from webkit-ews-12 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-12 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5
Created attachment 241597[details]
Archive of layout-test-results from webkit-ews-03 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-03 Port: mac-mountainlion Platform: Mac OS X 10.8.5
Created attachment 241615[details]
Archive of layout-test-results from webkit-ews-01 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-01 Port: mac-mountainlion Platform: Mac OS X 10.8.5
Created attachment 241716[details]
Archive of layout-test-results from webkit-ews-16 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-16 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5
Created attachment 241718[details]
Archive of layout-test-results from webkit-ews-08 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-08 Port: mac-mountainlion Platform: Mac OS X 10.8.5
Comment on attachment 241719[details]
Patch
View in context: https://bugs.webkit.org/attachment.cgi?id=241719&action=review> Source/WebCore/css/CSSPropertyNames.in:-363
> -align-items [NewStyleBuilder]
The idea is really to go in the other direction. We are working to port everything to the new StyleBuilder. It is going to be difficult if people move properties back to the old style builder :(
> Source/WebCore/css/CSSPropertyNames.in:-365
> -align-self [NewStyleBuilder, TypeName=EAlignItems]
Ditto.
Comment on attachment 241719[details]
Patch
View in context: https://bugs.webkit.org/attachment.cgi?id=241719&action=review> Source/WebCore/css/StyleResolver.cpp:2907
> + case CSSPropertyAlignSelf: {
Since you are now calling several setters on RenderStyle, you'll likely need to use [NewStyleBuilder, Custom=All] and move this code from StyleResolver.cpp to StyleBuilderCustom.h.
Comment on attachment 241719[details]
Patch
View in context: https://bugs.webkit.org/attachment.cgi?id=241719&action=review> Source/WebCore/css/StyleResolver.cpp:1377
> + if (style.alignItems() == ItemPositionAuto) {
> + if (style.isDisplayFlexibleOrGridBox())
> + style.setAlignItems(ItemPositionStretch);
> + else
> + style.setAlignItems(ItemPositionStart);
> + }
> +
> + // The 'auto' keyword computes to 'stretch' on absolutely-positioned elements,
> + // and to the computed value of align-items on the parent (minus
> + // any 'legacy' keywords) on all other boxes (to be resolved during the layout).
> + if (style.alignSelf() == ItemPositionAuto) {
> + if ((style.position() == AbsolutePosition))
> + style.setAlignSelf(ItemPositionStretch);
> + }
Looks like we will always overwrite values in RenderStyle now. That's not good since it will cause us to copy-on-write the StyleRareNonInheritedData.
This would be my first guess for the source of the performance regression.
Created attachment 241867[details]
Patch
Using now the new Style Builder, as requested. Also, removed the adjustStyleForAlignment method to avoid the performance regression; the required logic was moved to the computed style.
(In reply to comment #83)
> Comment on attachment 241719[details]
> Patch
>
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=241719&action=review
>
> > Source/WebCore/css/StyleResolver.cpp:1377
> > + if (style.alignItems() == ItemPositionAuto) {
> > + if (style.isDisplayFlexibleOrGridBox())
> > + style.setAlignItems(ItemPositionStretch);
> > + else
> > + style.setAlignItems(ItemPositionStart);
> > + }
> > +
> > + // The 'auto' keyword computes to 'stretch' on absolutely-positioned elements,
> > + // and to the computed value of align-items on the parent (minus
> > + // any 'legacy' keywords) on all other boxes (to be resolved during the layout).
> > + if (style.alignSelf() == ItemPositionAuto) {
> > + if ((style.position() == AbsolutePosition))
> > + style.setAlignSelf(ItemPositionStretch);
> > + }
>
> Looks like we will always overwrite values in RenderStyle now. That's not
> good since it will cause us to copy-on-write the StyleRareNonInheritedData.
> This would be my first guess for the source of the performance regression.
You are right; this was the root cause of the performance regression. I've submitted a new patch which avoids this, but I had to move the required logic to the computed style declaration bits.
I must mention, though, that current approach is enough for this patch but I think we will have to find other solutions when advancing on the implementation of the Box Alignment spec. The fact that 'auto' values are resolved to different values depending on the kind of elements, plus the hierarchic nature of the CSS logic makes some of the specification statements difficult to fulfil.
(In reply to comment #81)
> Comment on attachment 241719[details]
> Patch
>
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=241719&action=review
>
> > Source/WebCore/css/StyleResolver.cpp:2907
> > + case CSSPropertyAlignSelf: {
>
> Since you are now calling several setters on RenderStyle, you'll likely need
> to use [NewStyleBuilder, Custom=All] and move this code from
> StyleResolver.cpp to StyleBuilderCustom.h.
Implemented that way in the last patch. Could you please review it ? Thanks.
Created attachment 241872[details]
Archive of layout-test-results from webkit-ews-16 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-16 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5
Comment on attachment 241874[details]
Patch
View in context: https://bugs.webkit.org/attachment.cgi?id=241874&action=review
Looks like you might have one layout test failing on EWS?
> Source/WebCore/css/CSSPropertyNames.in:367
> +align-items [NewStyleBuilder, Custom=All]
Changes to this file look fine to me, but I am not the right person to review this change as a whole.
> Source/WebCore/css/StyleBuilderCustom.h:402
> +inline void applyInheritAlignSelf(StyleResolver& styleResolver)
Changes to this file look fine to me, but I am not the right person to review this change as a whole.
Created attachment 241886[details]
Archive of layout-test-results from webkit-ews-09 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-09 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5
Created attachment 241889[details]
Archive of layout-test-results from webkit-ews-01 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-01 Port: mac-mountainlion Platform: Mac OS X 10.8.5
Hi Antii,
(In reply to comment #98)
> > LayoutTests/TestExpectations:72
> > +webkit.org/b/133359 mathml/presentation/style-changed.html [ ImageOnlyFailure ]
> > +webkit.org/b/136291 platform/mac/accessibility/webkit-alt-for-css-content.html [ Failure ]
> > +webkit.org/b/136291 platform/mac/accessibility/alt-for-css-content.html [ Failure ]
>
> Why is this patch making these tests fail?
The mathml patch fails because of the spec change which specifies 'auto' as default for the alignment properties, instead of 'stretch'. Such 'auto' value has to be resolved during the style cascade depending on the kind of element; 'stretch' for flex and grid containers, 'start' otherwise. The MathML implementation relies on the RenderFlexibleBox render to get such 'stretch' effect but it's not an actual flex element, from the CSS point of view. Also, it artificially manipulates the styles to get the desired behavior.
In the case of the accessibility patches it's a collateral effect of the style adjust by the StyleResolver, to resolve the auto' values, which forced a copy of the StlyeRareNonInheritedData structure (note that this copy was removed in the last patch because of the performance regression it introduces). The problem as, described in bug #136291, is that the m_altText field is not being copied as it should.
(In reply to comment #100)
> How are you going to solve these failures?
The accessibility tests failure would be solved with the patch attached in bug ##136291. Also worth mentioning that my path does not cause those test to fail, but just triggering an already present bug. Additionally, the root cause which triggered the accessibility related bug is the code added, in previous versions of this patch, into the StyleResolver::adjustStyleForAlignment function. This logic, even I consider it as a good approach, caused some performance regression so it was removed in the last version of the patch. Anyway, the accessibility bugs are still present because it's something it was not implemented correctly for the atlText property.
The mathml tests fail because the stretch CSS properties are not being handled correctly, specifically regarding the 'stretch' value and how it was implemented for mathml. The solution might need an important re-design of the mathml layout logic, which it was already discussed with some of the reviewers of such module and agreeing on that approach; it's just that it will take time so I think it's better to skip the test for the time being.
>
> I think Hyatt should review this.
Actually hyatt reviewed the previous version of the patch, the one using the StyleResolver::adjustStyleForAlignment logic, which I think is the proper way to resolve the 'auto' values of the css alignment properties. That's indeed the key issue to clarify in this discussion, since the original approach of updating the RenderStyle properties caused a performance regression, as kling pointed out in comment #83.
The Box Alignment specification introduces 2 aspects that makes this patch more complicated than it should:
1- The initial value for all the CSS properties is 'auto', which will be resolved to 'stretch' for Grid/Flex elements, or 'start' otherwise.
2- The 'auto' value of {align, justify}-self properties will be resolved to the '{align, justify}-items resolved value in the parent.
The final version of the patch avoids the performance regression duplicating the 'auto' value resolution logic in the CSSCOmputedStyleDeclaration and in the specific RenderObjects (Flex or Grid, in this case).
So, this is an issue about CSS parsing and how we would like to face the current behavior of the CSS alignment properties, based from now on on the CSS Box Alignment specification.
Are you planning to work on a refined version of the patch? If so, please remove the r? cq? flags as they will make the patch appear in the review queue.
(In reply to comment #103)
> Are you planning to work on a refined version of the patch? If so, please
> remove the r? cq? flags as they will make the patch appear in the review
> queue.
Well, last patch fixes the bug and avoids the performance regression. While it might be not the best approach, it's still valid for continue the discussion here. I can't continue working on this without the proper feedback about the issues commented above, so I think 'r' flag still applies.
Created attachment 248558[details]
Archive of layout-test-results from ews105 for mac-mavericks-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews105 Port: mac-mavericks-wk2 Platform: Mac OS X 10.9.5
Created attachment 248562[details]
Archive of layout-test-results from ews105 for mac-mavericks-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews105 Port: mac-mavericks-wk2 Platform: Mac OS X 10.9.5
Created attachment 248563[details]
Archive of layout-test-results from ews102 for mac-mavericks
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews102 Port: mac-mavericks Platform: Mac OS X 10.9.5
Comment on attachment 248569[details]
Patch
View in context: https://bugs.webkit.org/attachment.cgi?id=248569&action=review
r-
> Source/WebCore/css/CSSComputedStyleDeclaration.cpp:2133
> + if (style->position() != AbsolutePosition) {
> + Node* parent = styledNode->parentNode();
> + if (parent && parent->computedStyle()) {
> + alignSelf = resolveAlignmentAuto(parent->computedStyle()->alignItems(), parent);
> + overflow = parent->computedStyle()->alignItemsOverflowAlignment();
> + }
> + }
Why not use the render tree here? This code just looks completely wrong to me because it's trying to look at the DOM. For example, you left out FixedPositioned (render tree would just use isOutOfFlowPositioned), and you're going to the DOM parent (what if that is not in the same place in the render tree)?
Created attachment 248934[details]
Archive of layout-test-results from ews102 for mac-mavericks
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews102 Port: mac-mavericks Platform: Mac OS X 10.9.5
Created attachment 248935[details]
Archive of layout-test-results from ews106 for mac-mavericks-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews106 Port: mac-mavericks-wk2 Platform: Mac OS X 10.9.5
2014-07-11 15:23 PDT, Javier Fernandez
2014-07-11 16:33 PDT, Build Bot
2014-07-11 17:23 PDT, Build Bot
2014-07-11 18:23 PDT, Build Bot
2014-07-12 03:16 PDT, Javier Fernandez
2014-07-30 14:59 PDT, Javier Fernandez
2014-07-30 15:53 PDT, Javier Fernandez
2014-07-30 17:44 PDT, Build Bot
2014-07-30 18:26 PDT, Build Bot
2014-07-30 19:00 PDT, Build Bot
2014-07-30 19:51 PDT, Build Bot
2014-08-01 14:03 PDT, Javier Fernandez
2014-08-01 15:20 PDT, Build Bot
2014-08-01 15:57 PDT, Build Bot
2014-08-01 16:13 PDT, Javier Fernandez
2014-08-01 17:22 PDT, Build Bot
2014-08-01 18:25 PDT, Build Bot
2014-08-01 18:41 PDT, Build Bot
2014-08-21 08:32 PDT, Javier Fernandez
2014-08-21 10:19 PDT, Build Bot
2014-08-21 10:51 PDT, Build Bot
2014-08-21 11:20 PDT, Build Bot
2014-08-25 06:04 PDT, Javier Fernandez
2014-08-25 08:24 PDT, Build Bot
2014-08-25 08:57 PDT, Build Bot
2014-08-25 09:54 PDT, Build Bot
2014-08-27 06:39 PDT, Javier Fernandez
2014-10-27 16:03 PDT, Javier Fernandez
2014-11-12 01:57 PST, Javier Fernandez
2014-11-12 02:04 PST, Javier Fernandez
2014-11-12 06:39 PST, Javier Fernandez
2014-11-12 07:56 PST, Javier Fernandez
2014-11-13 02:40 PST, Javier Fernandez
2014-11-13 20:46 PST, Build Bot
2014-11-13 22:58 PST, Build Bot
2014-11-14 08:38 PST, Javier Fernandez
2014-11-14 10:09 PST, Build Bot
2014-11-14 10:52 PST, Build Bot
2014-11-14 13:00 PST, Build Bot
2014-11-17 06:46 PST, Javier Fernandez
2014-11-17 08:17 PST, Build Bot
2014-11-17 08:38 PST, Build Bot
2014-11-17 09:30 PST, Javier Fernandez
2014-11-19 10:19 PST, Javier Fernandez
2014-11-19 11:42 PST, Build Bot
2014-11-19 12:16 PST, Javier Fernandez
2014-11-19 13:51 PST, Build Bot
2014-11-19 14:38 PST, Build Bot
2014-11-19 15:00 PST, Javier Fernandez
2015-03-12 16:55 PDT, Javier Fernandez
2015-03-12 17:40 PDT, Build Bot
2015-03-12 17:50 PDT, Javier Fernandez
2015-03-12 18:37 PDT, Build Bot
2015-03-12 19:10 PDT, Build Bot
2015-03-12 23:03 PDT, Javier Fernandez
2015-03-18 07:46 PDT, Javier Fernandez
2015-03-18 08:56 PDT, Build Bot
2015-03-18 09:00 PDT, Build Bot
2015-03-18 09:17 PDT, Javier Fernandez