QA/Firefox3.1/FontFace TestStatus: Difference between revisions

From MozillaWiki
< QA‎ | Firefox3.1
Jump to navigation Jump to search
Line 79: Line 79:
** The latter feature reproduced on firefox 3.0.x, even on the pages that was not using downloadable fonts
** The latter feature reproduced on firefox 3.0.x, even on the pages that was not using downloadable fonts
** The former feature reproduced only on nightly builds with the patch applied.
** The former feature reproduced only on nightly builds with the patch applied.
Bugs not filed in Bugzilla yet:
* After applying the patch v.0.9, firefox hung when trying to load the page using downloadable fonts
** It hung only when the src:url() specifies valid url of the font
*** valid url: file exists, and does not violate same-site origin restriction
** stack dump [https://wiki.mozilla.org/QA/Firefox3.1/FontFace_hung_attachment335684 here]
* The layout after the new fonts load seems to be based on the old layout, as is mentioned in [https://bugzilla.mozilla.org/show_bug.cgi?id=441473#c33 bug 441473 #33]
* The layout after the new fonts load seems to be based on the old layout, as is mentioned in [https://bugzilla.mozilla.org/show_bug.cgi?id=441473#c33 bug 441473 #33]
Suspected features (are these bug? or expected behaviors?)
* Fallback function not working on Mac OS X
* Fallback function not working on Mac OS X
** When it fails to download the font from every URI written in src, it just doesn't display anything ... shouldn't it display in default font?
** When it fails to download the font from every URI written in src, it just doesn't display anything ... shouldn't it display in default font?
** Also, when the url written in src did exist but was not in a proper format, it displays nothing. Even if they had other candidates after that url, those candidates are ignored.
** Also, when the url written in src did exist but was not in a proper format, it displays nothing. Even if they had other candidates after that url, those candidates are ignored.
Suspected features (are these bug? or expected behaviors?)
* Some fonts have more than two font names (ex. HiraKakuPro-W3 and ヒラギノ角ゴ Pro W3). src:local() cannot recognize font names written in Japanese
* Some fonts have more than two font names (ex. HiraKakuPro-W3 and ヒラギノ角ゴ Pro W3). src:local() cannot recognize font names written in Japanese
** Normal font-family: ""; can recognize font names written in Japanese
** Normal font-family: ""; can recognize font names written in Japanese

Revision as of 23:48, 28 August 2008

« QA/Firefox3.1/FontFace TestPlan

Notes

@font-face test status Test Plan: @font-face TestPlan

Executed Tests

(Tests Already Executed)

Tests marked with star (*) shows that some unexpected features were found. See Possible Risks section for details.

Tests on Mac OS X

Combination Tests for the following features:

Font Face serif, sans-serif, cursive, Asian, Arabic
Font Format TrueType, OpenType, TrueType-AAT(Apple Advanced Typography), EOT(Microsoft Embedded OpenType)
Source url, local
File Encoding Western, UTF-8, Shift_JIS, and other language-specific encodings

Font name tests

  • Font with multiple names (*)
  • When family-name was overrode by @font-face rules

Font source tests

  • Fallback function tests (*)

Rules tests

  • when multiple @font-face rules was in a single file
  • when multiple font face was assigned to a single font-family by @font-face
    • font matching algorithm (font-weight, font-style, font-stretch) (*)
    • how CSS marksups and HTML tags affect (*)

Others

  • Tests to make sure downloaded fonts cannot be used from other documents
  • Printing Test
  • Same origin policy test (*)

Tests on Windows XP SP3

5% of Combination Tests (*)

  • Waiting for the further patch
    • since src:local() is under progress, some tests cannot be executed
    • also, some fonts do not display when I use src:url() too

Planned (but not executed) Tests

(Tests Not Executed Yet)

See　the TestPlan for details.

Possible Risks

(Known bugs, not-yet-implemented features, questions)

Bugs already Filed in bugzilla:

  • Firefox crashes when you leave the page before the font download finishes.
  • Unknown gryph change happens to some Japanese characters when font (which does not contain Japanese characters) is downloaded and rendered.
    • Now filed as bug 451426
    • It happens when the file is encoded in Japanese encoding (Shift_JIS, EUC-jp). But it also happened on files encoded in UTF-8.
    • As written in bug 451426, this feature can be divided into two features
      • Some characters are rendered incorrectly from the moment it's loaded
      • Some characters are rendered differently after you re-focus on the firefox window
    • The latter feature reproduced on firefox 3.0.x, even on the pages that was not using downloadable fonts
    • The former feature reproduced only on nightly builds with the patch applied.

Bugs not filed in Bugzilla yet:

  • After applying the patch v.0.9, firefox hung when trying to load the page using downloadable fonts
    • It hung only when the src:url() specifies valid url of the font
      • valid url: file exists, and does not violate same-site origin restriction
    • stack dump here
  • The layout after the new fonts load seems to be based on the old layout, as is mentioned in bug 441473 #33
  • Fallback function not working on Mac OS X
    • When it fails to download the font from every URI written in src, it just doesn't display anything ... shouldn't it display in default font?
    • Also, when the url written in src did exist but was not in a proper format, it displays nothing. Even if they had other candidates after that url, those candidates are ignored.

Suspected features (are these bug? or expected behaviors?)

  • Some fonts have more than two font names (ex. HiraKakuPro-W3 and ヒラギノ角ゴ Pro W3). src:local() cannot recognize font names written in Japanese
    • Normal font-family: ""; can recognize font names written in Japanese
  • Font-weight, font-style and font-stretch descriptors seems to be ignored
    • It seems that only data in the font itself is used to determine the characteristics of downloadable fonts
    • Font-stretch property itself is not implemented yet

Expected Features

  • No support for EOT, dataFork TrueType, Bitmap Fonts

Bugs that will reproduce on Firefox 3.0.x (that means, these bugs are not coming from the patch code, but from the codes already implemented and landed)

  • Some fonts are not rendered on Windows
    • When these fonts are used in downloadable fonts (@font-face), it simply doesn't work, and fallback function will be called
    • When these fonts are used in normal font-family rules, the layout changes, but the face does not change
      • faces will change in IE7, so Windows OS recognizes the face. But firefox somehow doesn't.
    • It doesn't have relationship with font formats like TrueType or OpenType. Some OpenType fonts are drawn correctly, and some are not drawn.
    • When it fails, message like the following is displayed on the console:
    • List of succeeded fonts: Arial Black, Scheherazade-AAT, Scheherazade-OT, Tahoma, Verdana, JaneAusten
    • List of failed fonts: Hiragino Kaku Gothic ProN W3, Hiragino Mincho ProN, Nadeem, Chalkborad, Steve Regular
  • Unknown gryph change happens to some Japanese characters when font (which does not contain Japanese characters) is downloaded and rendered.
    • details described above
Retrieved from "https://wiki.allizom.org/index.php?title=QA/Firefox3.1/FontFace_TestStatus&oldid=106391"