Re: Outline of a plan to remove all XUL documents from mozilla-central

[Brendan Dahl]

https://bugzilla.mozilla.org/show_bug.cgi?id=1550801


On Wed, May 15, 2019 at 6:30 AM Gijs Kruitbosch 
wrote:

> On 14/05/2019 16:32, Brian Grinstead wrote:
> >> 1. Load all XUL documents as XHTML using the prototype cache. This
> >> doesn’t require any file renaming, we will just detect a .xul file
> and act
> >> like it’s .xhtml. This is tracked in bug 1550801
> >> .
>
> There doesn't seem to be a bug on file listed in that tracking bug for
> actually doing the "detect a .xul file and act like it's .xhtml" bit. Is
> there one already on file?
>
> I think this step makes me the most nervous - we need to make sure that
> we don't change web-observable behaviour, and that the "no remote XUL"
> prohibitions continue to apply. In theory, that should all be fine
> because of XHTML and namespaces, but I figured it was worth flagging up.
>
> ~ Gijs
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

XUL Overlays Removed

[Brendan Dahl]

This is hopefully the last thing you’ll ever hear about XUL overlays as
they have now been completely removed from Firefox[1]. For those unfamiliar
with overlays, they provided a way to merge two XUL documents and were
mainly used by legacy extensions and in several places within the Firefox
UI. While overlays served a purpose, they were removed since we no longer
support legacy extensions and they added unneeded complexity to Firefox.

Removing overlays cut around 3.5K lines of code from Firefox and in my
opinion made understanding which resources get loaded into which documents
easier to reason about (see one example of a before[2] and after[3] below).
This is just one piece of the broader XUL removal effort, but it does
highlight that things can be simpler in a post-XUL world.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1426763

[2] https://bug1441378.bmoattachments.org/attachment.cgi?id=8954951

[3] https://bug1441378.bmoattachments.org/attachment.cgi?id=8954952

Key:

Arrow direction: where elements go from -> to.

Red: MacOS only

Green: Non-MacOS

Blue: where the  element went
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: HTML injection in chrome documents is now automatically sanitized

[Brendan Dahl]

Would it be very difficult to warn when something is sanitized and removed?

I wasted a good deal of time trying to figure out why
createContextualFragment wasn't working.

On Fri, Feb 2, 2018 at 2:10 AM, Gijs Kruitbosch 
wrote:

> FWIW, if you're running into this with the usecase "I have a localized
> string that needs to have links (or other markup) in it" and were formerly
> using getFormattedString combined with innerHTML, we now have a utility
> method that can help a little bit. Rather than hand-rolling splitting the
> string etc., on nightly you can use BrowserUtils.getLocalizedFragment as
> a replacement. Given a document, raw string (fetch using getString /
> GetStringFromName instead of the "formatted" APIs), and DOM nodes to
> insert, it'll produce a DocumentFragment that you can
> appendChild/insertBefore etc., take care of splitting your strings for you,
> and will work with both indexed (%1$S) and non-indexed (%S) replacement
> points in the localized string. In the further future, I expect this type
> of problem will go away entirely because of Fluent.
>
> ~ Gijs
>
>
> On 02/02/2018 07:13, Kris Maglione wrote:
>
>> As of bug 1432966, any HTML injected into chrome-privileged documents[1]
>> is automatically sanitized to remove any possibility of script execution.
>> The sanitization is whitelist-based, and only allows a limited set of HTML
>> elements and attributes. All scripts, XUL nodes, or privileged URLs will
>> automatically be removed. This change has been uplifted all the way to 58
>> release.
>>
>> If you're thinking about writing new code that injects HTML strings into
>> chrome-privileged documents, please think again. Unless it's extremely
>> simple, it probably won't be compatible with these changes (and will also
>> be rejected by our default ESLint rules).
>>
>> Existing HTML injection in chrome documents is being gradually removed.
>> Once that's done, the sanitization may be replaced with an outright
>> prohibition.
>>
>>
>> -Kris
>>
>> [1]: Using the usual HTML fragment creation methods such as `innerHTML`,
>> `outerHTML`, `insertAdjacentHTML`, and `createContextualFragment`. Not,
>> notably, when using document.write().
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

A less intrusive way to run mochitest-plain

[Brendan Dahl]

I just landed support for running mochitest-plain tests in headless mode.
Next time you want to run some mochitests and not be bothered by Firefox
opening and demanding focus, just add ---headless to ./mach test. Headless
mochitest-plain is supported on Windows, MacOS, and Linux.

./mach test --headless [path/to/test/]

A few notes:

- Headless mode tries to mimic native platform behavior, but it's not
possible in all cases. Tests meant to exercise code in the
widget/ directory (e.g. window size changes, clipboard events,
etc) may have slightly different behavior than the native widget code and
should be tested in both headless and normal mode.

- Issues with headless mode should be filed under Firefox->Headless [1]

- Headless mochitest-plain tests are also running in automation. On
TaskCluster they show up as h<#>.

- We could potentially start running mochitests in parallel and I’ve filed
a bug [2] to look into that.

-Brendan

[1]
https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox=Headless

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1419135
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Shipping Headless Firefox on Linux

[Brendan Dahl]

Supporting a "--headless" flag for the web platform tests would be great. I
think we should keep running all the tests in a real environment but try to
get all of them running in headless as well. Most of the failures will be
fixed by some work I did in the windows support bug[1]. I'll look into it
and potentially uplift some of those changes. I've filed bug to track
this[2].

[1] = https://bugzilla.mozilla.org/show_bug.cgi?id=1355150
[2] = https://bugzilla.mozilla.org/show_bug.cgi?id=1373739


On Thu, Jun 15, 2017 at 11:45 PM, James Graham <ja...@hoppipolla.co.uk>
wrote:

> On 15/06/17 21:51, Ben Kelly wrote:
>
>> On Thu, Jun 15, 2017 at 4:37 PM, Nathan Froyd <nfr...@mozilla.com> wrote:
>>
>> On Thu, Jun 15, 2017 at 2:02 PM, Brendan Dahl <bd...@mozilla.com> wrote:
>>>
>>>> Headless will run less of the platform specific widget code and I don't
>>>> recommend using it for platform specific testing. It is targeted more at
>>>> web developers and testing regular content pages. There definitely will
>>>>
>>> be
>>>
>>>> cases where regular pages will need to exercise code that would vary per
>>>> platform (such as fullscreen), but hopefully we can provide good enough
>>>> emulation in headless and work to have a consistent enough behavior
>>>>
>>> across
>>>
>>>> platforms that it won't matter.
>>>>
>>>
>>> Would it be feasible to use headless mode for mochitests (or reftests,
>>> etc. etc.)?  I know there are probably some mochitests which care
>>> about the cases you mention above (e.g. fullscreen), but if that could
>>> be taken care of in the headless code itself or we could annotate the
>>> tests somehow, it would be a huge boon for running mochitests locally,
>>> or even in parallel.  (We already have some support for running
>>> reftests/crashtests in parallel.)
>>>
>>>
>> There are some tests which fail if the "screen" is not a particular size.
>> Those might be a problem as well.
>>
>
> FWIW [1] is a try run of web-platform-tests in headless mode. There are
> clearly some tests that are broken. If people thought it was high value I
> could add a --headless command line argument with support for running most
> tests in headless and specially annotated tests in a real window. But it
> wouldn't be possible to keep that annotation data up to date automatically
> with new imports, so it would be a best-effort solution.
>
> [1] https://treeherder.mozilla.org/#/jobs?repo=try=e428
> 2575210badf4ab3a072d5ceab51ee2384e11=linux
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Shipping Headless Firefox on Linux

[Brendan Dahl]

Dan and Andreas bring up points that I was going to add, but to further it
a bit more:

Running tests in the correct real environment is important and I think we'd
have to be very cautious of running tests in headless mode only. I see
headless more as a complimentary testing mode, where you have 99% of the
guts of Firefox, but a much nicer workflow for testing. I'm hoping with
headless Firefox and headless Chrome it will be much easier for developers
to run test suites in these environments where the browser is much closer
to the real thing as opposed to something like PhantomJS or just testing a
node environment.

On Fri, Jun 16, 2017 at 6:22 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com>
wrote:

> On 06/15/2017 04:37 PM, Nathan Froyd wrote:
>
>> On Thu, Jun 15, 2017 at 2:02 PM, Brendan Dahl <bd...@mozilla.com> wrote:
>>
>>> Headless will run less of the platform specific widget code and I don't
>>> recommend using it for platform specific testing. It is targeted more at
>>> web developers and testing regular content pages. There definitely will
>>> be
>>> cases where regular pages will need to exercise code that would vary per
>>> platform (such as fullscreen), but hopefully we can provide good enough
>>> emulation in headless and work to have a consistent enough behavior
>>> across
>>> platforms that it won't matter.
>>>
>> Would it be feasible to use headless mode for mochitests (or reftests,
>> etc. etc.)?
>>
> Running the tests that we rely on for correctness on an environment that
> looks this different than the environment that our users run sounds like a
> bad thing to do.  What would be the advantage of doing so?
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Shipping Headless Firefox on Linux

[Brendan Dahl]

The width and height can be adjusted with the environment variables
MOZ_HEADLESS_WIDTH and MOZ_HEADLESS_HEIGHT. We don't currently support DPI
changes, but it shouldn't be too hard to add.

On Thu, Jun 15, 2017 at 1:51 PM, Ben Kelly <bke...@mozilla.com> wrote:

> On Thu, Jun 15, 2017 at 4:37 PM, Nathan Froyd <nfr...@mozilla.com> wrote:
>
>> On Thu, Jun 15, 2017 at 2:02 PM, Brendan Dahl <bd...@mozilla.com> wrote:
>> > Headless will run less of the platform specific widget code and I don't
>> > recommend using it for platform specific testing. It is targeted more at
>> > web developers and testing regular content pages. There definitely will
>> be
>> > cases where regular pages will need to exercise code that would vary per
>> > platform (such as fullscreen), but hopefully we can provide good enough
>> > emulation in headless and work to have a consistent enough behavior
>> across
>> > platforms that it won't matter.
>>
>> Would it be feasible to use headless mode for mochitests (or reftests,
>> etc. etc.)?  I know there are probably some mochitests which care
>> about the cases you mention above (e.g. fullscreen), but if that could
>> be taken care of in the headless code itself or we could annotate the
>> tests somehow, it would be a huge boon for running mochitests locally,
>> or even in parallel.  (We already have some support for running
>> reftests/crashtests in parallel.)
>>
>
> There are some tests which fail if the "screen" is not a particular size.
> Those might be a problem as well.
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Shipping Headless Firefox on Linux

[Brendan Dahl]

I ran a few mochitests in headless mode awhile ago, so it's definitely
feasible. I haven't looked into it much more yet, as I'm still trying to
get a basic level of support to each platform.

On Thu, Jun 15, 2017 at 1:37 PM, Nathan Froyd <nfr...@mozilla.com> wrote:

> On Thu, Jun 15, 2017 at 2:02 PM, Brendan Dahl <bd...@mozilla.com> wrote:
> > Headless will run less of the platform specific widget code and I don't
> > recommend using it for platform specific testing. It is targeted more at
> > web developers and testing regular content pages. There definitely will
> be
> > cases where regular pages will need to exercise code that would vary per
> > platform (such as fullscreen), but hopefully we can provide good enough
> > emulation in headless and work to have a consistent enough behavior
> across
> > platforms that it won't matter.
>
> Would it be feasible to use headless mode for mochitests (or reftests,
> etc. etc.)?  I know there are probably some mochitests which care
> about the cases you mention above (e.g. fullscreen), but if that could
> be taken care of in the headless code itself or we could annotate the
> tests somehow, it would be a huge boon for running mochitests locally,
> or even in parallel.  (We already have some support for running
> reftests/crashtests in parallel.)
>
> -Nathan
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Shipping Headless Firefox on Linux

[Brendan Dahl]

At the moment, headless isn't much different than running with xvfb
(besides being more convenient than installing xvfb). For the first stage,
performance hasn't been the priority, but we expect some improvements and
we'll be starting some work on this soon.

Headless will run less of the platform specific widget code and I don't
recommend using it for platform specific testing. It is targeted more at
web developers and testing regular content pages. There definitely will be
cases where regular pages will need to exercise code that would vary per
platform (such as fullscreen), but hopefully we can provide good enough
emulation in headless and work to have a consistent enough behavior across
platforms that it won't matter.

On Thu, Jun 15, 2017 at 8:57 AM, Ben Kelly <bke...@mozilla.com> wrote:

> I typically use xvfb-run when executing tests locally.  How does headless
> mode differ?  Does it just run faster, but at the cost not testing some
> widget code?
>
> On Wed, Jun 14, 2017 at 7:51 PM, Brendan Dahl <bd...@mozilla.com> wrote:
>
>> Hello All,
>>
>>
>> As of Firefox 55 I intend to ship headless Linux support (Firefox without
>> a
>> GUI and X11 server connection). Headless mode is enabled via the
>> --headless
>> command line flag for Firefox and does not affect Firefox when running in
>> normal mode or on Windows and macOS
>>
>>
>>
>> For those unfamiliar with the project, the main goal of headless browsing
>> is to make web developer workflow and testing with Firefox easier. There
>> are currently two ways to interact with headless Firefox by using either
>> SlimerJS or Marionette (WebDriver/Selenium).
>>
>>
>>
>> Testing:
>>
>> The Marionette test suite is now run in headless mode alongside the normal
>> mode as a tier 2 test on try. There are also some basic xpcshell tests
>> that
>> use a simple headless browser. If the Marionette tests remain reliable, I
>> intend to bump them up to tier 1 in a few weeks [1].
>>
>>
>>
>> In the near future, I'll also be enabling headless mode on Windows and
>> then
>> will start work on macOS. We also are going to investigate some possible
>> performance improvements for headless mode.
>>
>>
>>
>> If you run into any issues please file a bug in the new headless component
>> [2].
>>
>>
>>
>> More info:
>>
>>
>>
>> Meta bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1338004
>>
>> Linux support: https://bugzilla.mozilla.org/show_bug.cgi?id=1356681
>>
>> Windows support: https://bugzilla.mozilla.org/show_bug.cgi?id=1355150
>>
>> MacOS support: https://bugzilla.mozilla.org/show_bug.cgi?id=1355147
>>
>> [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1373029
>>
>> [2]:
>> https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox
>> omponent=Headless
>> .
>>
>>
>>
>> Previous blog post on SlimerJS support:
>> https://adriftwith.me/coding/2017/04/21/headless-slimerjs-with-firefox/
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Shipping Headless Firefox on Linux

[Brendan Dahl]

Depending on how the dialog was triggered, it may just work in headless
mode. To run the test in headless mode, add "headless = true" to the test
in your xpcshell.ini. Also, if you're in headless mode you can check it by
calling gfxPlatform::IsHeadless() in c++.

On Thu, Jun 15, 2017 at 12:27 AM, ishikawa <ishik...@yk.rim.or.jp> wrote:

> On 2017年06月15日 08:51, Brendan Dahl wrote:
> > Hello All,
> >
> >
> > As of Firefox 55 I intend to ship headless Linux support (Firefox
> without a
> > GUI and X11 server connection). Headless mode is enabled via the
> --headless
> > command line flag for Firefox and does not affect Firefox when running in
> > normal mode or on Windows and macOS
> >
> >
> >
> > For those unfamiliar with the project, the main goal of headless browsing
> > is to make web developer workflow and testing with Firefox easier. There
> > are currently two ways to interact with headless Firefox by using either
> > SlimerJS or Marionette (WebDriver/Selenium).
> >
> >
> >
> > Testing:
> >
> > The Marionette test suite is now run in headless mode alongside the
> normal
> > mode as a tier 2 test on try. There are also some basic xpcshell tests
> that
> > use a simple headless browser. If the Marionette tests remain reliable, I
> > intend to bump them up to tier 1 in a few weeks [1].
> >
> >
> >
> > In the near future, I'll also be enabling headless mode on Windows and
> then
> > will start work on macOS. We also are going to investigate some possible
> > performance improvements for headless mode.
> >
> >
> >
> > If you run into any issues please file a bug in the new headless
> component
> > [2].
> >
>
> This sounds interesting.
>
> On local machine, when I added a modal error dailog as a response to an
> error condition, which happens to be  artificially created and tested in
> xpcshell test, the test fails because the screen or whatever is not
> available. Fair enough, but it was rather disappointing to see such a
> feature needed to be disabled due to xpcshell test failing.
>
> Does this new approach take care of such an issue in a more or less
> developer-friendly manner? Maybe we have a global flag to see if
> the program runs in headless mode?
> (Then I can do "if(!headless_mode) show the dialog on the screen", etc.)
>
> TIA
>
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Shipping Headless Firefox on Linux

[Brendan Dahl]

Hello All,


As of Firefox 55 I intend to ship headless Linux support (Firefox without a
GUI and X11 server connection). Headless mode is enabled via the --headless
command line flag for Firefox and does not affect Firefox when running in
normal mode or on Windows and macOS



For those unfamiliar with the project, the main goal of headless browsing
is to make web developer workflow and testing with Firefox easier. There
are currently two ways to interact with headless Firefox by using either
SlimerJS or Marionette (WebDriver/Selenium).



Testing:

The Marionette test suite is now run in headless mode alongside the normal
mode as a tier 2 test on try. There are also some basic xpcshell tests that
use a simple headless browser. If the Marionette tests remain reliable, I
intend to bump them up to tier 1 in a few weeks [1].



In the near future, I'll also be enabling headless mode on Windows and then
will start work on macOS. We also are going to investigate some possible
performance improvements for headless mode.



If you run into any issues please file a bug in the new headless component
[2].



More info:



Meta bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1338004

Linux support: https://bugzilla.mozilla.org/show_bug.cgi?id=1356681

Windows support: https://bugzilla.mozilla.org/show_bug.cgi?id=1355150

MacOS support: https://bugzilla.mozilla.org/show_bug.cgi?id=1355147

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1373029

[2]:
https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox=Headless
.



Previous blog post on SlimerJS support:
https://adriftwith.me/coding/2017/04/21/headless-slimerjs-with-firefox/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Including Adobe CMaps

[Brendan Dahl]

Yury Delendik worked on reformatting the files a bit and was able to get them 
down to 1.1MB binary which gzips to 990KB. This seems like a reasonable size to 
me and involves a lot less work than setting up a process for distributing 
these files via CDN.

Brendan

On Feb 24, 2014, at 10:14 PM, Rik Cabanier caban...@gmail.com wrote:

 
 
 
 On Mon, Feb 24, 2014 at 5:01 PM, Andreas Gal andreas@gmail.com wrote:
 
 My assumption is that certain users only need certain CMaps because they tend 
 to read only documents in certain languages. This seems like something we can 
 really optimize and avoid ahead-of-time download cost for.
 
 So, you'd only install the Korean CMaps if the language is Korean?
 The problem with that is that if a user might install a English version of 
 Firefox but still open Korean PDFs (which will then display as junk)
  
 
 The fact that we don’t do this yet doesn’t seem like a good criteria. There 
 is a lot of good things we aren’t doing yet. You can be the first to change 
 that on this particular topic, if it technically makes sense.
 
 Load-on-demand (with an option to download all of them) seems like a nice 
 solution. A large majority of users will never need CMaps or only a very 
 small subset.
  
 On Feb 25, 2014, at 1:27 AM, Brendan Dahl bd...@mozilla.com wrote:
 
  It’s certainly possible to load dynamically. Do we currently do this for 
  any other Firefox resources?
 
  From what I’ve seen, many PDF’s use CMaps even if they don’t necessarily 
  have CJK characters, so it may just be better to include them. FWIW both 
  Popper and Mupdf embed the CMaps.
 
  Brendan
 
  On Feb 24, 2014, at 3:01 PM, Andreas Gal andreas@gmail.com wrote:
 
  Is this something we could load dynamically and offline cache?
 
  Andreas
 
  Sent from Mobile.
 
  On Feb 24, 2014, at 23:41, Brendan Dahl bd...@mozilla.com wrote:
 
  PDF.js plans to soon start including and using Adobe CMap files for 
  converting character codes to character id's(CIDs) and mapping character 
  codes to unicode values. This will fix a number of bugs in PDF.js and 
  will improve our support for Chinese, Korean, and Japanese(CJK) documents.
 
  I wanted to inform dev-platform because there are quite a few files and 
  they are large. The files are loaded lazily as needed so they shouldn't 
  affect the size of Firefox when running, but they will affect the 
  installation size. There are 168 files with an average size of ~40KB, and 
  all of the files together are roughly:
  6.9M
  2.2M when gzipped
 
  http://sourceforge.net/adobe/cmap/wiki/Home/
 
  ___
  dev-platform mailing list
  dev-platform@lists.mozilla.org
  https://lists.mozilla.org/listinfo/dev-platform
 
 
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Including Adobe CMaps

[Brendan Dahl]

PDF.js plans to soon start including and using Adobe CMap files for converting 
character codes to character id’s(CIDs) and mapping character codes to unicode 
values. This will fix a number of bugs in PDF.js and will improve our support 
for Chinese, Korean, and Japanese(CJK) documents.

I wanted to inform dev-platform because there are quite a few files and they 
are large. The files are loaded lazily as needed so they shouldn’t affect the 
size of Firefox when running, but they will affect the installation size. There 
are 168 files with an average size of ~40KB, and all of the files together are 
roughly:
6.9M
2.2M when gzipped

http://sourceforge.net/adobe/cmap/wiki/Home/

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Including Adobe CMaps

[Brendan Dahl]

It’s certainly possible to load dynamically. Do we currently do this for any 
other Firefox resources? 

From what I’ve seen, many PDF’s use CMaps even if they don’t necessarily have 
CJK characters, so it may just be better to include them. FWIW both Popper and 
Mupdf embed the CMaps.

Brendan

On Feb 24, 2014, at 3:01 PM, Andreas Gal andreas@gmail.com wrote:

 Is this something we could load dynamically and offline cache?
 
 Andreas
 
 Sent from Mobile.
 
 On Feb 24, 2014, at 23:41, Brendan Dahl bd...@mozilla.com wrote:
 
 PDF.js plans to soon start including and using Adobe CMap files for 
 converting character codes to character id's(CIDs) and mapping character 
 codes to unicode values. This will fix a number of bugs in PDF.js and will 
 improve our support for Chinese, Korean, and Japanese(CJK) documents.
 
 I wanted to inform dev-platform because there are quite a few files and they 
 are large. The files are loaded lazily as needed so they shouldn't affect 
 the size of Firefox when running, but they will affect the installation 
 size. There are 168 files with an average size of ~40KB, and all of the 
 files together are roughly:
 6.9M
 2.2M when gzipped
 
 http://sourceforge.net/adobe/cmap/wiki/Home/
 
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform