MiniApp Test Results

More details about this document
Latest published version:
https://w3c.github.io/miniapp-tests/results
Latest editor's draft:
https://w3c.github.io/miniapp-tests/drafts/results
History:
Commit history
Editor:
Martin Alvarez-Espinar (Huawei)
Feedback:
GitHub w3c/miniapp-tests (pull requests, new issue, open issues)
public-miniapp@w3.org with subject line [miniapp-tests-results] … message topic … (archives)

Abstract

Results of MiniApp Testing.

Status of This Document

This document is merely a W3C-internal document. It has no official standing of any kind and does not represent consensus of the W3C Membership.

1. Introduction

This document contains the test results for all tests. There is a separate document giving a short description for each tests; these descriptions are linked from the the tests in the tables below.

Some implementations may come in different "variants": though they have identical MiniApp engines, their behaviors may slightly diverge in different environments (typically iOS, Android, or Web) and, therefore, they are reported separately from one another. From the W3C Process point of view, these variants should not considered to be independent implementations and, therefore, they should be considered as one implementation as far as the formal Candidate Recommendation report is concerned. On the other hand, implementors may see a value in keeping those implementation results separated.

The report tables below reflect this duality. 3.1 Consolidated Implementation Results shows a view of the reports where reports with identical core engines, albeit in different variants, are displayed as if it was a single implementation. The test results for a specific test is set to true if any of the variants has a true value. On the other hand, the separate 3.2 Detailed Implementation Results keeps all the variants separate, showing the full implementation results.

2. List of Implementations lists all the implementations with the variant in parenthesis, if applicable.

The report tables also include a separate column (with the heading "Req") providing the conformance level for the feature being tested (i.e., must, should, or may).

Strictly speaking, the should and may tests are not necessary for the official CR testing of the specifications. These tests are currently visible in the tables below; to change their visibility, click the switch visibility button below.

The development of the tests is a community effort (see the list of contributors). Everyone is welcome to contribute tests; please read the separate contribution guidelines if you are interested in doing so.

2. List of Implementations

    3. Implementations Results

    3.1 Consolidated Implementation Results

    3.1.1 Packaging

    IdReq
    pkg-css-global-supportmust
    pkg-pages-same-filenamesmust
    pkg-root-app-css-emptymay

    3.1.2 Manifest

    IdReq
    mnf-window-background-colormust
    mnf-window-background-color-defaultmust
    mnf-window-fullscreen-defaultmust
    mnf-window-fullscreen-truemust
    mnf-window-orientation-defaultmust
    mnf-window-orientation-landscapemust
    mnf-window-orientation-portraitmust

    3.1.3 Lifecycle

    IdReq
    lcy-global-launched-callback-page-pathmust

    3.2 Detailed Implementation Results

    3.2.1 Packaging

    IdReq
    pkg-css-global-supportmust
    pkg-pages-same-filenamesmust
    pkg-root-app-css-emptymay

    3.2.2 Manifest

    IdReq
    mnf-window-background-colormust
    mnf-window-background-color-defaultmust
    mnf-window-fullscreen-defaultmust
    mnf-window-fullscreen-truemust
    mnf-window-orientation-defaultmust
    mnf-window-orientation-landscapemust
    mnf-window-orientation-portraitmust

    3.2.3 Lifecycle

    IdReq
    lcy-global-launched-callback-page-pathmust