QA/Firefox3.1/FontFace TestStatus: Difference between revisions
Ayoshihara (talk | contribs) |
Ayoshihara (talk | contribs) |
||
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] | ||
* 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.
- For example, the following test page should crash your firefox (only if have applied the patch for bug 441473).
- http://people.mozilla.org/~ctalbert/fontface/downloadable-font-crashtest.html
- Now filed as bug 451462
- 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
- It hung only when the src:url() specifies valid url of the font
- 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:
- (06D65018) nsFontFaceLoader OnStopRequest http://www.example.jp/example.otf font construction failed
- 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