Re: Intent to ship: MouseEvent.offsetX/Y
On Mon, Mar 2, 2015 at 7:00 PM, Chris Peterson wrote: > Gecko's offsetX/Y could return doubles, for compatibility with the spec, > that are always snapped to whole numbers, for compatibility with other > browsers. > > Or Gecko could add random noise to the low bits of offsetX/Y so they are > *never* whole numbers. Web developers would need to handle fuzzy results > today, thus preparing for more precise results in the future. :) > Let's not overthink this :-) Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
dev-platform@lists.mozilla.org
It looks like the current one should already be as the the AssignASCII
will be inlined into the caller and then the strlen can be inlined as
well.
-Jeff
On Sun, Mar 1, 2015 at 7:04 PM, smaug wrote:
> On 03/02/2015 01:11 AM, Xidorn Quan wrote:
>>
>> On Mon, Mar 2, 2015 at 9:50 AM, Boris Zbarsky wrote:
>>
>>> On 3/1/15 5:04 PM, Xidorn Quan wrote:
>>>
Hence I think we should remove this method. All callees should use
either
AssignLiteral(MOZ_UTF16("some string")), or, if don't want to bloat the
binary, explicitly use AssignASCII("some string").
>>>
>>> The latter requires an strlen() that AssignLiteral optimizes out, right?
>>>
>>
>> Yes, so we can add another overload to AssignASCII which does this
>> optimization
>
> How would you do that?
>
>> with less misleading.
>>
>> - Xidorn
>>
>
> ___
> 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
Intent to ship *on pre-release channels* : vertical text support (CSS writing-mode and related properties)
See [1] for additional background on this feature. We are aiming to enable support for CSS writing-mode and related features (i.e. vertical text support) in Gecko 39.[2] This will be enabled behind an #ifndef RELEASE_BUILD condition, so that for the time being, these features will be available by default in developer builds, but not in the release version. Once more key parts of CSS layout have been adapted to support vertical mode, we'll remove the condition and enable writing-mode by default on release as well as dev channels.[3] cc'ing firefox-dev and dev-gaia lists, particularly to make people aware that while we encourage experimentation with the new properties (please test and file bugs!), you should not attempt to use them in front-end code that will ship to release channels where writing-mode remains disabled-by-default for now. JK [1] https://www.mail-archive.com/dev-platform@lists.mozilla.org/msg12343.html [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1099032 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1138384 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
dev-platform@lists.mozilla.org
On 03/02/2015 02:41 PM, Jeff Muizelaar wrote:
It looks like the current one should already be as the the AssignASCII
will be inlined into the caller and then the strlen can be inlined as
well.
Well AssignLiteral doesn't use strlen at all and that is the whole point of
AssignLiteral.
Can some template magic guarantee that if AssignASCII deals with literals too,
the strlen-less version is used when possible?
The original issue was
"The method name AssignLiteral can easily make people at the callee side
think it makes the string point to a piece of static data, which has no
runtime penalty. But this is false."
Can we somehow make use of nsDependentString easier? (not that I think it is
hard. The name is just a bit long)
-Olli
-Jeff
On Sun, Mar 1, 2015 at 7:04 PM, smaug wrote:
On 03/02/2015 01:11 AM, Xidorn Quan wrote:
On Mon, Mar 2, 2015 at 9:50 AM, Boris Zbarsky wrote:
On 3/1/15 5:04 PM, Xidorn Quan wrote:
Hence I think we should remove this method. All callees should use
either
AssignLiteral(MOZ_UTF16("some string")), or, if don't want to bloat the
binary, explicitly use AssignASCII("some string").
The latter requires an strlen() that AssignLiteral optimizes out, right?
Yes, so we can add another overload to AssignASCII which does this
optimization
How would you do that?
with less misleading.
- Xidorn
___
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
Test Informant Report - Week ending Feb 28
Test Informant report for 2015-02-28. State of test manifests at revision eea6188b9b05. Using revision 86d2bb8bb1c9 as a baseline for comparisons. Showing tests enabled or disabled between 2015-02-22 and 2015-02-28. 85% of tests across all suites and configurations are enabled. Summary --- marionette- ↑0↓0 - 92% mochitest-a11y- ↑0↓0 - 99% mochitest-browser-chrome - ↑160↓16 - 94% mochitest-browser-chrome-e10s - ↑48↓6 - 63% mochitest-chrome - ↑8↓0 - 96% mochitest-plain - ↑87↓0 - 84% mochitest-plain-e10s - ↑32↓0 - 79% xpcshell - ↑71↓0 - 86% Full Report --- http://brasstacks.mozilla.com/testreports/weekly/2015-02-28.informant-report.html ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
dev-platform@lists.mozilla.org
Xidorn Quan wrote:
The method name AssignLiteral can easily make people at the callee side think
it makes the string point to a piece of static data, which has no runtime
penalty. But this is false.
Actually nsACString::AssignLiteral used to copy too until I fixed it
last year.
Hence I think we should remove this method. All callees should use either
AssignLiteral(MOZ_UTF16("some string")), or, if don't want to bloat the binary,
explicitly use AssignASCII("some string").
I already tried that, but AssignASCII takes a const char* parameter
which has an implicit conversion from a string literal thus making it
impossible to overload with a template. I do have a patch somewhere that
changes most of the tree to use AssignLiteral(MOZ_UTF16()) if you're
interested.
--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Syncing 2 scrolling operations
On Sat, Feb 28, 2015 at 3:47 AM, Paul Rouget wrote: > > How much work is that? Is it just a matter of "piping" things together > to expose an JS method to privileged code? > Not really - I think we would have to add new APIs to manipulate the layer tree of child processes from the parent process. I'm not entirely opposed to doing this but I think it would be a good idea to investigate other use cases that might impact this and design an API that is sufficiently general to handle all of those use cases. It's one of those things where even slight changes in the UX might require significant changes on the platform side, so it's worth coming up with something general enough to allow flexibility in the UX. kats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Proposed W3C Charter: WebRTC Working Group
The W3C is proposing a revised charter for: Web Real-Time Communications Working Group http://www.w3.org/2015/02/webrtc-charter.html https://lists.w3.org/Archives/Public/public-new-work/2015Feb/0004.html Mozilla has the opportunity to send comments or objections through Friday, March 13. Please reply to this thread if you think there's something we should say as part of this charter review. (Given our involvement, it seems to me like we should support the charter in general, possibly with comments.) -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Proposed W3C Charters: All Groups, Web Accessibility Initiative (WAI)
The W3C is proposing revised charters for nearly all of the working groups in the Web Accessibility Initiative (all except Independent User Interface): https://lists.w3.org/Archives/Public/public-new-work/2015Feb/0007.html Accessible Platform Architectures Working Group (APA WG) (Formerly the Protocols and Formats Working Group) http://www.w3.org/2012/10/draft-pfwg-charter Web Content Accessibility Guidelines Working Group (WCAG WG) http://www.w3.org/2013/04/draft-wcag-charter Authoring Tool Accessibility Guidelines Working Group (ATAG WG) http://www.w3.org/WAI/AU/2013/draft_auwg_charter.html User Agent Accessibility Guidelines Working Group (UAWG) http://www.w3.org/WAI/UA/2013/draft_uawg_charter Evaluation and Repair Tools Working Group (ERT WG) http://www.w3.org/WAI/ER/charter5.html Education and Outreach Working Group (EOWG) http://www.w3.org/WAI/EO/2013/charter6 Research and Development Working Group (RDWG) http://www.w3.org/WAI/RD/charter4.html WAI Interest Group (WAI IG) http://www.w3.org/WAI/IG/charter5.html WAI Coordination Group (WAI CG) http://www.w3.org/WAI/CG/charter5.html Mozilla has the opportunity to send comments or objections through Monday, March 23. Please reply to this thread if you think there's something we should say as part of this charter review, or whether you think we should explicitly abstain. (Note that we can only explicitly abstain from the set of charters as a whole, not individually, at least on the ballot form, though I suppose we could do so in prose.) -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: MouseEvent.offsetX/Y
On 3/1/15 17:58, smaug wrote: Haven't changes from integer to doubles caused issues in some cases. Boris might recall some examples. IE just reverted from using doubles on MouseEvent for compat reasons: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28029#c6 -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charters: All Groups, Web Accessibility Initiative (WAI)
On Mon, Mar 2, 2015 at 7:57 PM, L. David Baron wrote: > Please reply to this thread if you think there's something we should > say as part of this charter review, or whether you think we should > explicitly abstain. (Note that we can only explicitly abstain from > the set of charters as a whole, not individually, at least on the > ballot form, though I suppose we could do so in prose.) High-level comments that might be worth making would be: 1) Stop any kind of Member-only activity. Require coordination and discussion in public. 2) Merge the public discussion list and the WG list as e.g. WebApps and other groups have it so everyone is on equal footing. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: MouseEvent.offsetX/Y
On Tue, Mar 3, 2015 at 8:49 AM, Mike Taylor wrote: > On 3/1/15 17:58, smaug wrote: > >> Haven't changes from integer to doubles caused issues in some cases. >> Boris might recall some examples. >> > > IE just reverted from using doubles on MouseEvent for compat reasons: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=28029#c6 > Ah, that's good to know! I'll change offsetX/Y to long then. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
MemShrink Meeting - Tuesday, 3 Mar 2015 at 2:00pm PST
The next Memshrink meeting is is brought to you by the Shumway project: http://www.areweflashyet.com/shumway/ The wiki page for this meeting is at: https://wiki.mozilla.org/Performance/MemShrink Agenda: * Review Shumway memory reports/usage * Prioritize unprioritized MemShrink bugs. * Discuss how we measure progress. * Discuss approaches to getting more data. * Schedule next meeting time (DST coming up!) Meeting details: * Tue, 3 Mar 2015, 2:00 PM PST * http://arewemeetingyet.com/Los%20Angeles/2015-03-03/14:00/MemShrink%20Meeting * Vidyo: Memshrink * Dial-in Info: - In office or soft phone: extension 92 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92 - Toll-free: 800-707-2533 then password 369 - Conference num 98802 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: CSS Scroll Snapping on B2G / Firefox OS
As of March 3, 2014 I intend to turn on by default CSS Scroll Snapping on B2G. It has been developed behind the layout.css.scroll-snap.enabled preference. Firefox is the first UA to ship this feature. Platform coverage: Initially, this will be enabled only on B2G (Firefox OS). Desktop platforms will be enabled once scroll bar support for CSS scroll snapping lands (Bug 969250). Fennec will be enabled once the C++ based APZC implementation ships for Fennec (Bug 1138668). This feature was previous discussed in this "intent to implement" thread: https://groups.google.com/forum/#!topic/mozilla.dev.platform/HX9lwWZ250o/discussion Feedback during the draft updates on the css-snappoints specification took place on the w3.org www-style mailing list. Bug to turn on by default: Bug 1138651 - Enable CSS Scroll Snapping by Default on B2G Link to standard: http://dev.w3.org/csswg/css-snappoints/ The entirety of the W3 specification is implemented, with one exception. In section 4 (Scroll Snap Types: the 'scroll-snap-type' property), the specification reads, "If the content changes such that the visual viewport would no longer rest on a snap point (e.g. content is added, moved, deleted, resized), the scroll offset must be modified to maintain this guarantee.". Support for this is tracked in Bug 1124324 (Perform instant and smooth scrolls to maintain guarantees set by scroll snapping CSS attributes when content changes) and will be landed separately. - Kearwood "Kip" Gilbert ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charters: All Groups, Web Accessibility Initiative (WAI)
Anne, David, Le 3 mars 2015 à 05:15, Anne van Kesteren a écrit : > 1) Stop any kind of Member-only activity. Require coordination and > discussion in public. It seems it's part of their intent without stopping totally. Some groups indeed seem to be in between In http://www.w3.org/2012/10/draft-pfwg-charter > • Kept group chartered to operate in Member space when needed, but stated > that work will now default to public space. Existing projects will be moved > to public space, though legacy resources (old minutes, issue tracking, etc.) > cannot be moved due to confidentiality change restrictions. In http://www.w3.org/2013/04/draft-wcag-charter > Some communications between editors may be member-confidential. In http://www.w3.org/WAI/AU/2013/draft_auwg_charter.html > Proceedings are Public. Some communications between editors and/or during the > implementation testing period may be member-confidential. In http://www.w3.org/WAI/UA/2013/draft_uawg_charter > Some communications between editors and/or during the implementation testing > period may be member-confidential. > … > Proceedings are Public. Some communications between editors and/or during the > implementation testing period may be member-confidential. The only group which stays completely Member-only is the WAI Coordination Group Charter In http://www.w3.org/WAI/CG/charter5.html > Proceedings are Member-only This is strange given that the list of Group dependencies are public only groups. http://www.w3.org/WAI/CG/charter5.html#coordination And in the list of activities, there is nothing which seems to require Member-only confidentiality. Checking their mailing list archives I do not see anything which seem to require to be Member Confidential. https://lists.w3.org/Archives/Member/w3c-wai-cg/ Or to the opposite most messages seem of public interest. -- Karl Dubost, Mozilla http://www.la-grange.net/karl/moz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: CSS Grid Layout Module Level 1
On Monday, February 2, 2015 at 5:20:21 PM UTC-5, Mats Palmgren wrote: > Summary: > CSS Grid defines a two-dimensional grid-based layout system, optimized for > user interface design. In the grid layout model, the children of a grid > container can be positioned into arbitrary slots in a flexible or fixed > predefined layout grid. > > Bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=css-grid > > Link to standard: > CSS Grid Layout Module Level 1 > http://dev.w3.org/csswg/css-grid/ > > Platform coverage: > All Gecko platforms and products. > > Estimated or target release: > TBD > > Preference behind which this will be implemented: > layout.css.grid.enabled > > > /Mats Glad to hear, looking forward to testing ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
