Closed Bug 748250 (ringmark-ring1) Opened 12 years ago Closed 8 years ago

Pass ringmark ring 1

Categories

(Core Graveyard :: Tracking, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: mounir, Unassigned)

References

Details

Attachments

(1 file)

      No description provided.
Alias: ringmark-ring1
Went through these today out of curiosity. The tests aren't that good and I expect they'll change, but here's what I see now.

Checks for element.style.someCssProperty and vendor prefixed versions of it that we fail:
  animationName
  borderImageSource
  borderImageSlice
  borderImageWidth
  borderImageOutset
  borderImageRepeat
  borderImage
  overflowScrolling (is this a real thing?)
  transition
  boxSizing - not sure why these last two fail yet...

CSSText tests use styleElement.innerText which we don't support.

We don't support navigator.onLine in workers. Need to file a bug for that.

WebRTC and HTML Forms aren't supported yet.

Tests that need fixing:
MediaQuery tests check if a MediaQueryList object matches its own "matches" property (i.e. a boolean). They also require that the browser screen be less than 500px wide.

Transform tests are testing nothing, but they still manage to fail. Why they would check that in, I don't know.

The HashChange test waits for an onhashchange event, but never changes the page's hash.
The CSS fonts tests are all failing, and the parts of the tests that I understood are bogus (though I didn't follow the whole thing).  I'd expect us to pass based on the descriptions.
Depends on: 767565
(In reply to Wesley Johnston (:wesj) from comment #1)
>   animationName

We support this.

>   borderImageSource
>   borderImageSlice
>   borderImageWidth
>   borderImageOutset
>   borderImageRepeat
>   borderImage

We support these.

>   overflowScrolling (is this a real thing?)

There is a Webkit-only overflow-scrolling property which we don't implement:
http://developer.apple.com/library/safari/#documentation/appleapplications/reference/SafariCSSRef/Articles/StandardCSSProperties.html#//apple_ref/css/property/-webkit-overflow-scrolling
This is not on any standards track AFAIK. I don't think Ringmark or any other cross-browser benchmark should test stuff that has no proposed spec.

>   transition
>   boxSizing - not sure why these last two fail yet...

We support these.
It seems the various Touch events don't work on Desktop Firefox, but I assume they do on Mobile? Mobile gets a higher score on Ring 1 than Desktop does, but I couldn't see the results because the dropdown doesn't seem to work in Gecko. (I was able to get the results on Desktop by using a little Firebug magic.)
Yes. You could try enabling them on desktop by setting dom.w3c_touch_events.enabled to true. We should talk about doing that by default. It might be useful (even on non-touch machines) for sites that want to write for touch first, and then redirect mouse events to touch events. I know Paul Roget has told me he is doing that in places.
I was looking at this last week while investigating a different bug and thought I'd update this. We're actually doing much better now I think. Note rng.io has a bug that makes it impossible to expand the results for us. Running with rng.io/?all will run all three rings which masks the bug.

The tests are still pretty awful. Mostly just testing for the existence of css properties and not checking the quality or correctness of implementations yet. Right now we just fail:

overflowScrolling - IMO we should not support this. Site authors use it to work around some bugs in iOS. I'd rather we just didn't have the bugs. There is no spec for this feature. I've filed an issue with facebook to remove the test.

box-sizing - We support this. Its an existence test for boxSizing in div.style (plus prefixed versions). Something wrong with the test.

input-types: Patches for date-time support are landing leaving just color and range support. I don't expect the date-time pieces to make us pass those tests either (I don't think we're validating input yet?).

media-capture: We support HTML5's capture stuff. They're testing for a slightly different API http://www.w3.org/TR/html-media-capture/. I think there's confusion here because HTML5 specifies a way forward for the most common use case and the spec specifies a highly specialized use case (this picture much be captured by the camera right now) that I'm not even sure we want encourage? I'll file something with Facebook about this as well.
(In reply to Wesley Johnston (:wesj) from comment #6)
> input-types: Patches for date-time support are landing leaving just color
> and range support. I don't expect the date-time pieces to make us pass those
> tests either (I don't think we're validating input yet?).

We have patches nearly ready for <input type='date'> and patches WIP for <input type='time'>. However, that was done by an intern who left so we might need someone to finish them.
Matt from Facebook here (I work on Ringmark). I'll keep it short as I don't mean to hijack this thread.

Thanks for taking a look at the tests and sending over feedback. You're right that the tests need work--I expect they always will due to the web evolving quickly, particularly on mobile. We also need to write more tests. It's open source so that you can help us make it better, whether it's via PRs or by filing issues. Thanks for the issues filed so far, and let us know if you spot anything else.
Depends on: 825294
All rings run by default now (expanding works, too). The remaining work here (for Ring 1) are the missing <input> types, whereas the other "gray" tests fail due to unknown reasons (test bug?) or the check does not make sense (-webkit-overflow-scrolling).
Attached file Reduced input tests
I reduced the input type tests down because I was surprised we failed them (except range and color, and range passes with the pref flipped but only because the tests don't test much).

We fail datetime, datetime-local, week, and month because we don't return the correct type from input.type (strangely, they don't test for input[type='time']. Looking at our source code I realized that's not surprising. While we have special UI for these input types, we don't have much in the backend for them yet.
Esp. the input stuff is also linked on the html5test bug - https://bugzilla.mozilla.org/show_bug.cgi?id=html5test - the date/time ones are bug 825294 and bug 446510, mostly.
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #3)
> (In reply to Wesley Johnston (:wesj) from comment #1)
> >   animationName
> 
> We support this.
> 
> >   borderImageSource
> >   borderImageSlice
> >   borderImageWidth
> >   borderImageOutset
> >   borderImageRepeat
> >   borderImage
> 
> We support these.
> 
> >   overflowScrolling (is this a real thing?)
> 
> There is a Webkit-only overflow-scrolling property which we don't implement:
> http://developer.apple.com/library/safari/#documentation/appleapplications/
> reference/SafariCSSRef/Articles/StandardCSSProperties.html#//apple_ref/css/
> property/-webkit-overflow-scrolling
> This is not on any standards track AFAIK. I don't think Ringmark or any
> other cross-browser benchmark should test stuff that has no proposed spec.
> 
> >   transition
> >   boxSizing - not sure why these last two fail yet...
> 
> We support these.

You do NOT support boxSizing. It correctly fails. You support -moz-box-sizing. I would add that bug as a dependency. Its bug #243412.
Marking all tracking bugs which haven't been updated since 2014 as INCOMPLETE.
If this bug is still relevant, please reopen it and move it into a bugzilla component related to the work
being tracked. The Core: Tracking component will no longer be used.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: