Re: Intent to Prototype: Have window.outerHeight/outerWidth lie and report the innerHeight/innerWidth

[Masatoshi Kimura]

window.resizeTo() should also use innerHeight/innerWidth instead of
outerHeight/outerWidth. Otherwise web pages can open a popup, call
window.resizeTo(), and get innerHeight/innerWidth to circumvent the
restriction.

On 2019/09/08 13:57, Tom Ritter wrote:
> Summary:
> window.outerHeight/outerWidth are legacy properties that report the
> size of the outer window of the browser. By subtracting against
> innerHeight/innerWidth it exposes the size of the user's browser
> chrome which can be unique depending on customization, but at the
> least reveals non-standardized information that can be used for
> fingerprinting purposes.
> 
> I have a hard time figuring out how a website would use it for
> (legitimate|reasonable) rendering purposes. I discussed it with Anne
> and we'd like to neuter it and see if we can remove this
> fingerprintable information if possible.
> 
> Tor Browser (and RFP mode) has reported the values of
> innerHeight/innerWidth for outerHeight/outerWidth for a long time and
> I haven't seen or heard of any breakage caused as a result of that.
> 
> (We'll also need to spoof window.screenX and window.screenY as
> window.mozInnerScreenX and window.mozInnerScreenY respectively.)
> 
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1579584
> Standard: https://www.w3.org/TR/cssom-view-1/#dom-window-outerwidth
> Platform coverage: All, although TBH I don't know how this behaves on 
> Android...
> 
> Preference: Yes, this will be controlled by a preference that I'll
> flip for Nightly for now and watch for reports of breakage.
> 
> DevTools bug: n/a
> Other browsers: I haven't proposed this to any other browsers.
> web-platform-tests: I don't believe any WPT actually test for the
> correct value here.
> Secure contexts: This will be applicable everywhere
> 
> I considered adding telemetry for the properties; but reading them
> doesn't imply websites are relying on them for anything.
> 
> -tom
> ___
> 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: Crash reports with Fission enabled are now indicated by DOMFissionEnabled = 1

[Masatoshi Kimura]

On 2019/07/06 6:54, Andrew McCreight wrote:
>> Here's an example of a crash report with DOMFissionEnabled:
>> https://crash-stats.mozilla.org/report/index/dac0a91a-ad57-4446-9a82-505a80190705#tab-metadata

I could not find `DOMFissionEnabled` in this crash report (although
`DOMIPCEnabled` is found). Does it require some privileges due to
privacy reasons?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The tree has been reformatted now!

[Masatoshi Kimura]

Unfortunately, the ‘format-source’ extension did not work for me. Please
see .

On 2018/11/30 23:46, Andi-Bogdan Postelnicu wrote:
> Hello all
> 
> Starting with revision 6f3709b3878117466168c40affa7bca0b60cf75b 
> 
>  mozilla-central has been formatted using ./mach clang-format following the 
> Google coding style. 
> In order to diminish as much as possible the effort of merging pre-format 
> patches into our newly formatted repo we devised the following plan for the 
> two SCMs that we use:
> 
> Mercurial
> 
> Please make sure you run ‘mach bootstrap’ and allow the install of the 
> ‘format-source’ extension before pulling the reformat changeset. This 
> extension provides a simple and behind-the-curtains way on how you can 
> integrate un-formatted code into a formatted repo. 
> 
> Example
> Let’s assume the patch that need rebasing is at rev: 1000 and mozilla-central 
> is at rev: 2000.
> 
> hg rebase -b 1000 -d 2000
> 
> Or in case you want to have a more verbose output:
> 
> hg rebase -b 1000 -d 2000 -debug
> 
> The extension registers at the merge level and it will format both sides and 
> after that uses the original merge tool to combine for the final result.
> 
> For more detailed information on the process please also see this 
> 
>  document.
> 
>  Git
> Courtesy of Ehsan and Emilio there are two ways that help with the merge:
> Ehsan’s implementation 
> 
> Emilio’s implementation 
> For your convenience, the parent changeset of the reformat changeset has been 
> tagged in Mercurial as “PRE_TREEWIDE_CLANG_FORMAT”.  This will allow easily 
> updating to that version using the following command for example when 
> rebasing local changes:
> 
> hg up -r PRE_TREEWIDE_CLANG_FORMAT
> 
> 
> Hope this transition goes smooth as possible but if something comes up and 
> you need assistance please ping Andi on IRC.
> 
> Many thanks,
> Ehsan, Sylvestre and Andi 
> 
> ___
> 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: error while building a release(official) version on window error: Gecko exception wrapping doesn't understand your your MSVC/SDK. Please file a bug describing this error and your build configurati

[Masatoshi Kimura]

You cannot build Firefox 62 or earlier using Visual Studio 2017 Update 8
because of .

On 2018/11/07 0:28, Amirhossein Ghafari wrote:
> Hi,
> 
> I'm trying to build the release version of the firefox on the windows host.
> 
> The problem is I can easily follow the build instruction for windows provided 
> (https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Windows_Prerequisites)
>  but when I'm trying to compile a released version like 
> (https://archive.mozilla.org/pub/firefox/releases/62.0/source/firefox-62.0.source.tar.xz)
>  I will get the error in the building process.
> 
> I'm so frustrated right now I would shake your hand if you tell me what's 
> wrong.
> 
> here is the error:
> 
>  0:41.82 checking for dia2.h... yes
>  0:43.66 checking for overridable _RAISE... no
>  0:43.66 configure: error: Gecko exception wrapping doesn't understand your 
> your MSVC/SDK.  Please file a bug describing this error and your build 
> configuration.
>  0:43.67 DEBUG: 
>  0:43.67 DEBUG: configure:2433: checking for ranlib
>  0:43.67 DEBUG: configure:2465: checking for ml
>  0:43.67 DEBUG: configure:2519: checking for ar
>  0:43.67 DEBUG: configure:2554: checking for strip
>  0:43.67 DEBUG: configure:2589: checking for windres
>  0:43.67 DEBUG: configure:2624: checking for otool
>  0:43.67 DEBUG: configure:2726: checking for midl
>  0:43.67 DEBUG: configure:2775: cl.exe -c  -TC -nologo  conftest.c 1>&5
>  0:43.67 DEBUG: conftest.c
>  0:43.67 DEBUG: configure:2800: cl.exe -c  -TP -nologo  conftest.C 1>&5
>  0:43.67 DEBUG: conftest.C
>  0:43.67 DEBUG: configure:2851: checking for dia2.h
>  0:43.67 DEBUG: configure:2864: cl.exe -c  -TC -nologo  conftest.c 1>&5
>  0:43.67 DEBUG: conftest.c
>  0:43.67 DEBUG: configure:2978: checking for overridable _RAISE
>  0:43.67 DEBUG: configure:3005: cl.exe -c  -TP -nologo -w15038 -wd5026 
> -wd5027 -Zc:sizedDealloc- -wd4091 -wd4577 -D_HAS_EXCEPTIONS=0  conftest.C 1>&5
>  0:43.67 DEBUG: conftest.C
>  0:43.67 DEBUG: 
> C:\PROGRA~2\MICROS~1\2017\COMMUN~1\VC\Tools\MSVC\1415~1.267\include\yvals.h(512):
>  warning C4005: '_RAISE': macro redefinition
>  0:43.67 DEBUG: configure(2997): note: see previous definition of '_RAISE'
>  0:43.67 DEBUG: configure: error: Gecko exception wrapping doesn't understand 
> your your MSVC/SDK.  Please file a bug describing this error and your build 
> configuration.
>  0:43.67 ERROR: old-configure failed
>  0:43.75 *** Fix above errors and then restart with\
>  0:43.75"c:/mozilla-build/bin/mozmake.EXE -f client.mk build"
>  0:43.77 mozmake.EXE: *** [client.mk:149: configure] Error 1
> 
> ___
> 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: overly strict eslint rules

[Masatoshi Kimura]

On 2017/12/25 6:31, Jonathan Kingston wrote:
> It has worked for me for quite some time just running ./mach lint
> filename.js after bootstrap.

I got the following error when I tried it just now:

---
$ mach lint browser/base/content/aboutDialog.js
eslint-plugin-html v2.0.3 should be v4.0.0.
ESLint is an old version, clobbering node_modules directory
Clobbering node_modules...
Installing eslint for mach using
"d:\mozilla-build\node-v8.1.4-win-x64\npm.cmd install --loglevel=error"...
npm ERR! code ENOLOCAL
npm ERR! Could not install from
"tools\lint\eslint\eslint-plugin-mozilla" as it does not contain a
package.json file.

npm ERR! A complete log of this run can be found in:
npm ERR!
C:\Users\\AppData\Roaming\npm-cache\_logs\2017-12-24T21_55_36_055Z-debug.log

Error installing eslint, aborting.
Could not find eslint!  We looked at the --binary option, at the ESLINT
environment variable, and then at your local node_modules path. Please
Install
eslint and needed plugins with:

mach eslint --setup

and try again.
A failure occured in the eslint linter.
? 1 problem (0 errors, 0 warnings, 1 failure)
---

It is a really frustrating task to run eslint (and keep a working
environment) on Windows.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Phabricator/Lando update, November 2017

[Masatoshi Kimura]

I went to the 2FA preference on BMO. For me, the only authentication
option was TOTP that requires a smartphone. I do not have a smartphone
like Mark.

How can I continue to contribute after we are forced to use Phabricator?
Mozilla no longer wants volunteer contributors?

On 2017/11/30 3:05, Mark Côté wrote:
> Right, I should have mentioned that. We are working right now on enforcing
> MFA for Phabricator via BMO. See
> https://bugzilla.mozilla.org/show_bug.cgi?id=1393950. Should go out next
> week.
> 
> Mark
> 
> On Nov 29, 2017 12:41 PM, "Andreas Tolfsen"  wrote:
> 
>> Also sprach Mark Côté:
>>
>>> We were hesitant to advertise this too widely in order not to create
>>> any confusion around the Quantum release, but now that that has
>>> settled down I am told it should be fine for anyone to start using
>>> it.  The instance is at https://phabricator.services.mozilla.com/
>>> and there are docs at
>>> https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html.
>>
>> I’ve been wanting to try out the new review tool, but the sign up
>> steps in the documentation fails to mention two-factor authentication.
>> The only option is ‘Mobile Phone App (TOTP)’ and if you, like me,
>> don’t have a smartphone it is seemingly impossible to create an
>> account.
>>
>> I would’ve thought it would delegate the MFA bit to Bugzilla, or
>> am I doing something wrong?
>>
>>
> ___
> 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: Dropping remains of support for non-UTF-8 file paths on Gtk platforms (was: Re: Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code)

[Masatoshi Kimura]

On 2017/12/04 20:19, Henri Sivonen wrote:
> I suggest that instead of delaying with a round of telemetry, we make
> all non-Windows platforms in nsNativeCharsetUtils.cpp use what's
> currently the OSX/Android code path.

+1

Some other data points:
* If by any chance a profile path contains non-ASCII characters on
non-UTF-8 UNIX systems, Firefox 57.0.1 must have broken the profile just
like 57.0 broke it on Windows. But we didn't hear any such complaints.

* Our GMP service assumes that the native encoding is always UTF-8
except Windows. Some media playbacks must have been broken on UNIX
systems unless the locale is UTF-8.

I agree that telemetry is waste of time in this case.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code

[Masatoshi Kimura]

I intentionally ignored non-UTF-8 UNIX locales because our support for
those locales is already half-broken and almost nobody cares about that.
For example, OS.File assumes that the filesystem encoding is always
UTF-8 on UNIX while nsIFile does not. This discrepancy caused a bug[1]
that did not get much attention.

I think it's time to stop pretending to support non-UTF-8 UNIX locales.

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

On 2017/11/30 7:09, Karl Tomlinson wrote:
> I've always found this confusing, and so I'll write down the
> understanding I've reached, in the hope that either it will help
> others, or others can help me by correcting if these are
> misunderstandings.
> 
> On Unix systems:
> 
>   `nativePath`
> 
>  contains the bytes corresponding to the native filename used
>  by native system calls.
> 
>   `path`
> 
>  is a UTF-16 encoding of an attempt to provide a human
>  readable version of the native filename.  This involves
>  interpreting native bytes according to the character encoding
>  specified by the current locale of the application as
>  indicated by nl_langinfo(CODESET).
> 
>  For different locales, the same file can have a different
>  `path`.
> 
>  The native bytes may not be valid UTF-8, and so if the
>  character encoding is UTF-8, then there may not be a valid
>  `path` that can be encoded to produce the same `nativePath`.
> 
>   It is best to use `nativePath` for working with filenames,
>   including conversion to URI, but use `path` when displaying
>   names in the UI.
> 
> On WINNT systems:
> 
>   `path`
> 
>  contains wide characters corresponding to the native filename
>  used by native wide character system APIs.  For at least most
>  configurations, I assume wide characters are UTF-16, in which
>  case this is also human readable.
> 
>   `nativePath`
> 
>  is an attempt to represent the native filename in the native
>  multibyte character encoding specified by the current locale
>  of the application.
> 
>  For different locales, I assume the same file can have a
>  different `nativePath`.
> 
>  I assume there is not necessarily a valid multibyte character
>  encoding, and so there may not be a valid `nativePath` that
>  can be decoded to produce the same `path`.
> 
>   It is best to use `path` for working with filenames.
>   Conversion to URI involves assuming `path` is UTF-16 and
>   converting to UTF-8.
> 
> The parameters mean very different things on different systems,
> and so it is not generally possible to write XP code with either
> of these, but Gecko attempts to do so anyway.
> 
> The numbers of applications not using UTF-8 and filenames not
> valid UTF-8 are much smaller on Unix systems than the numbers of
> applications not using UTF-8 and non-ASCII filenames on WINNT
> systems, and so choosing to work with `path` provides more
> compatibility than working with `nativePath`.
> ___
> 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

Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code

[Masatoshi Kimura]

On Windows, the native charset is not UTF-8. Using these functions will
cause bugs such as [1] or [2].

Note that you can't simply replace all GetNative(Target|Path) to
Get(Target|Path) + NS_ConvertUTF16toUTF8. It will make things *worse*.
If you are using the path in logs or serialization formats (such as
[3]), probably it's OK to use NS_ConvertUTF16toUTF8. But if you are
passing the path to Operating system API functions or CRT functions,
probably you should change the function to a wide character variant
instead of converting the Unicode path. If you are passing the path to
some third-party libraries, read the documentation (or even the source)
of the library to determine the encoding of the path. If the library
wants the native charset, you will have to leave GetNative(Target|Path)
until the library is fixed to accept wide character paths or UTF-8 paths.

If you are not sure what to do with the Get(Target|Path) result, please
do not hesitate to ask me.

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

Re: nsAutoConfig

[Masatoshi Kimura]

On 2017/10/31 19:22, Marco Castelluccio wrote:
> It is not covered by any automated test:
> https://codecov.io/gh/marco-c/gecko-dev/src/9ca76dcb7a5c61d33750e9718c02b11ba35c1032/extensions/pref/autoconfig/src/nsAutoConfig.cpp
> (this doesn't mean it isn't actually used ever, but it can be a clue).

Actually I wrote an automated test, although it is difficult for
coverage tools to find the usage:
https://bugzilla.mozilla.org/show_bug.cgi?id=1267567
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The future of commit access policy for core Firefox

[Masatoshi Kimura]

On 2017/03/10 14:00, Mike Hommey wrote:
> While we're talking about drag on productivity, there's already one that
> comes from autoland already, which is that you can't easily land fixups
> for stupid mistakes (like, a build failure on one platform, or other
> lame things that happen when things land).
> 
> You either have to get a sheriff to land the fixup for you on autoland,
> or to back you out, in which case you're back to square one and need to
> reland the whole thing.
> 
> If on top of that, you also need another round of reviews...

Yes, it is really frustrating and wasting bandwidth of both developers
and shriffs. It is one of reasons I dislike mozreview/autoland.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The future of commit access policy for core Firefox

[Masatoshi Kimura]

On 2017/03/10 6:53, Mike Connor wrote:
>- Two-factor auth must be a requirement for all users approving or
>pushing a change.

I have no mobile devices. How can I use 2FA?

Previously I was suggested to buy a new PC and SSD only to shorten the
build time. Now do I have to buy a smartphone only to contribute
Mozilla? What's the next?

-- 
vyv03...@nifty.ne.jp
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Faster gecko builds with IceCC on Mac and Linux

[Masatoshi Kimura]

Oh, my laptop has only 4 core and I won't buy a machine or a compiler
farm account only to develope Gecko because my machine works perfectly
for all my other puoposes.

This is not the first time you blame my poor hardware. Mozilla (you are
a Mozilla employee, aren't you?) does not want my contribution? Thank
you very much!

On 2016/07/06 4:12, Gregory Szorc wrote:
> On Tue, Jul 5, 2016 at 11:08 AM, Steve Fink  wrote:
> 
>> I work remotely, normally from my laptop, and I have a single (fairly
>> slow) desktop usable as a compile server.
>>
> 
> Gecko developers should have access to 8+ modern cores to compile Gecko.
> Full stop. The cores can be local (from a home office), on a machine in a
> data center you SSH or remote desktop into, or via a compiler farm (like
> IceCC running in an office).
> 
> If you work from home full time, you should probably have a modern and
> beefy desktop at home. I recommend 2x Xeon E5-2637v4 or E5-2643v4. Go with
> the E5 v4's, as the v3's are already obsolete. If you go with the higher
> core count Xeons, watch out for clock speed: parts of the build like
> linking libxul are still bound by the speed of a single core and the Xeons
> with higher core counts tend to drop off in CPU frequency pretty fast. That
> means slower libxul links and slower builds.
> 
> Yes, dual socket Xeons will be expensive and more than you would pay for a
> personal machine. But the cost is insignificant compared to your cost as an
> employee paid to work on Gecko. So don't let the cost of something that
> would allow you to do your job better discourage you from asking for
> something! If you hit resistance buying a dual core Xeon machine, ping
> Lawrence Mandel, as he possesses jars of developer productivity lubrication
> that have the magic power of unblocking purchase requests.
> ___
> 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: #include sorting: case-sensitive or -insensitive?

[Masatoshi Kimura]

On 2016/03/29 7:18, Jared Wein wrote:
> We need to be careful with shuffling around #includes as there can be
> ordering dependencies that are not obvious at a glance.

Especially, #include "Foo.h" should be put first in Foo.cpp regardless
of the alphabetical order to avoid introducing such dependencies.
(If Foo.h requires other headers, Foo.h should include them.)
The guideline should say about that.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Masatoshi Kimura]

On 2016/03/11 3:03, Benjamin Smedberg wrote:
> The motivation for this change is that we have continued failures that
> are specific to these old operating systems and don't have the resources
> on engineering teams to prioritize these bugs. Especially with the
> deployment of e10s we're seeing intermittent and permanently failures on
> MacOS 10.6 that we are not seeing elsewhere. We get very little testing
> of old MacOS versions from our prerelease testers and cannot dedicate
> much paid staff testing support to these platforms. We also have an
> increasingly fragile set of old hardware that supports automated tests
> on 10.6 and do not intend to replace this.

Some fullscreen tests are enabled only on 10.6:
https://dxr.mozilla.org/mozilla-central/source/dom/tests/mochitest/chrome/chrome.ini#40

This proposal will virtually disable the fullscreen tests on OS X.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: referrerpolicy attribute

[Masatoshi Kimura]

On 2016/01/04 16:54, Anne van Kesteren wrote:
> There should be, per the specification discussion. E.g.,
> 
>   function isSupported(token) {
> var ele = document.createElement("a")
> ele.referrerPolicy = token
> return ele.referrerPolicy === token
>   }

It didn't work because |ele.referrerPolicy = token| created the
"referrerPolicy" property on ele. This function will return true even if
the browser does not support referrerPolicy.

-- 
vyv03...@nifty.ne.jp
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merge moved to Thursday 29th

[Masatoshi Kimura]

I missed two commits for 44 branch.
https://treeherder.mozilla.org/#/jobs?repo=fx-team=6b3c99e54177
Uplift requests will not help because they are string changes.

On 2015/10/29 5:10, Sylvestre Ledru wrote:
> Hello,
> 
> Because we want to synchronize the release of 42 and 44 devedition (next
> Tuesday),
> we are planning to perform the merge tomorrow, Thursday.
> As a consequence, nightly = 45, aurora = 44 and beta = 43 (42 is already
> in release).
> This will give us enough time to validate the first aurora build.
> 
> I apologize for the very late notice. Of course, we will be friendly
> with uplift requests.
> 
> Sylvestre
> 
> 
> ___
> 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: Intent to ship: RC4 disabled by default in Firefox 44

[Masatoshi Kimura]

On 2015/09/02 1:56, Richard Barnes wrote:
> * 42/ASAP: Disable whitelist in Nightly/Aurora; no change in Beta/Release
> * 43: Disable unrestricted fallback in Beta/Release (thus allowing RC4 only
> for whitelisted hosts)
> * 44: Disable all RC4 prefs by default, in all releases

The whitelist contains not only RC4-exclusive servers but also TLS
version intolerant servers.
That said, it would not be a big deal because Chrome 45 has disabled
insecure fallback to TLS 1.0 [1].

[1] https://code.google.com/p/chromium/issues/detail?id=498998
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to and unship: SSLv3

[Masatoshi Kimura]

Summary: SSLv3 is an outdated and known broken security protocol. I'll
remove the support from Gecko completely.

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

Spec: https://tools.ietf.org/html/draft-ietf-tls-sslv3-diediedie-00

Platform coverage: All

Target release: Gecko 39. Chrome will also drop the support a few weeks
later. Also, SSLv3 support will remain in ESR 38 and Thunderbird 38.

Preference behind which this will be implemented: It is already disabled
behind a preference by default since Gecko 34.

-- 
vyv03...@nifty.ne.jp
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Improved ruby parsing in HTML with new tag omission rules

[Masatoshi Kimura]

On 2014/12/28 3:04, Michael[tm] Smith wrote:
 Further, I don't know of any typical case where if a base character
 is kana, why you'd ever want to display furigana/yomigana for it.

Ruby is not used only for furigana/yomigana. I know one example from a
very popular Japanese novel:
  ruby赤眼の魔王rtルビーアイ/rt/ruby
This is not the only example. I'm confident we could find many case from
some Japanese novels.
Probably your next word is It is not typical. or Statistics,
please.. But unlike Xidorn Quan, I'm not interested in what WHATWG
people are doing because I know they are not serious about ruby at all.
Feel free to mess around with the ruby spec.

 So as long as the spec is going to require UAs to resort to magic
 behavior, I think the magic could instead just be autohide any
 ruby annotations for kana characters.

How to determine what ruby annotation corresponds to what base
character if the character count does not match?
(Again, I'm not interested in your answer. I know whatever case the
WHATWG spec cannot deal with is not typical.)

-- 
vyv03...@nifty.ne.jp
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Studying Lossy Image Compression Efficiency, July 2014

[Masatoshi Kimura]

On 7/15/14 12:38 PM, stonecyp...@gmail.com wrote:
 Similarly there's a reason that people are still hacking video into
 JPEGs and using animated GIFs.

People are using animated GIFs, but animated GIFs people are using may
not be animated GIFs [1].

(2014/07/16 5:43), Chris Peterson wrote:
 Do Chrome and IE support JPEG2000? I can't find a clear answer online.
 The WONTFIX'd Firefox bug [1] says IE and WebKit/Blink browsers support
 JPEG2000 (but WebKit's support is only on OS X).

No, IE does not support JPEG2000. But IE9+ supports JPEG XR. Chrome does
not support both, but it supports WebP [2].

[1] http://techcrunch.com/2014/06/19/gasp-twitter-gifs-arent-actually-gifs/
[2] http://xkcd.com/927/

-- 
vyv03...@nifty.ne.jp
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Icon fonts in FxOS

[Masatoshi Kimura]

(2014/06/17 4:34), Jet Villegas wrote:
 1. Let people use the icon fonts anywhere. (ie. like MS WingDings can be 
 used for this purpose) 

Actually WingDings can NOT be used at least on desktop Firefox because
it does not have a unicode cmap. Does Firefox OS have an option to relax
this restriction?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Announcement: using decltype for lazily loaded function

[Masatoshi Kimura]

Hello,

I recently changed a way to declare function pointers to be loaded
lazily on Windows.
Traditionally, we have to write a function prototype manually to declare
a function pointer. Example:

typedef int (WINAPI *tMessageBoxW)(HWND, LPCWSTR, LPCWSTR, UINT);
tMessageBoxW messageBoxW =
(tMessageBoxW) GetProcAddress(user32, MessageBoxW);

This is boring and error prone.
However, the new C++ decltype can eliminate the hand-written prototypes:

decltype(MessageBoxW)* messageBoxW =
(decltype(MessageBoxW)*) GetProcAddress(user32, MessageBoxW);

This keyword is available since MSVC 10. I decided to introduce it to
Mozilla tree because Mozilla doesn't build on MSVC 9 or earlier.
Please see bug 969918 for more details.

Reagrds,
Masatoshi Kimura
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform