Re: On builds getting slower
On 28/08/2013 3:30 AM, Gregory Szorc wrote: ... Does anyone else see this libraries-always-rebuild behavior? Not me - although I see just a few small ones - relevant parts of the log: 5:20.54 webapprt.obj 5:21.01 webapprt.cpp 5:21.01 5:21.05 webapprt-stub.exe 5:21.07 MakeNSIS v2.46-Unicode - Copyright 1995-2009 Contributors ... 5:21.27 Output: o:\src\mozilla-git\central2\obj-i686-pc-mingw32\webapprt\win\instgen\webapp-uninstaller.exe ... 5:29.50 nsBrowserApp.obj 5:30.12 nsBrowserApp.cpp 5:30.12 5:30.15 firefox.exe 5:30.32Creating library firefox.lib and object firefox.exp 5:30.32 5:30.35 Embedding manifest from o:/src/mozilla-git/central2/browser/app/firefox.exe.manifest 5:31.38 MakeNSIS v2.46-Unicode - Copyright 1995-2009 Contributors ... 5:32.25 Output: o:\src\mozilla-git\central2\obj-i686-pc-mingw32\browser\installer\windows\instgen\helper.exe ... 5:32.69 MakeNSIS v2.46-Unicode - Copyright 1995-2009 Contributors ... 5:32.90 Output: o:\src\mozilla-git\central2\obj-i686-pc-mingw32\browser\installer\windows\instgen\maintenanceservice_installer.exe and that's it. Mark ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
How to observe selection range within input element
Hi all, I'm implementing b2g keyboard/IME api and encounter a problem with the selection range observing. We want to monitor the cursor position or selection range changes in current input element, which is a text input field or a content editable element receiving user's input. The cursor position or the selection range can be changed by 1) key events generated by virtual keyboard, 2) js code, 3) mouse events triggered by user. Currently we listen a pile of events(mousedown, mouseup, input...) to check if the selection range has been changed. It is inefficient and error prone. I wonder if there is a way to monitor the selection range changes from chrome js. Could anyone give me a clue? Thanks. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
padding/margin/border/content highlighting (need platform help)
For the devtools, we want to show the box model of the selected node. Screenshot (chrome): https://bug663778.bugzilla.mozilla.org/attachment.cgi?id=538850 We use the computed style and getBoundClientRect. - bug 381328 is blocking us (computed style of margin:auto returns 0). Can anyone help? (maybe mentor me?) - is there any better way than using the computed style + getBoundClientRect? Maybe we can expose the layout info to nsIDOMWindowUtils, or maybe we can highlight these regions directly at the gecko level. -- Paul ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: On builds getting slower
On 8/28/2013 3:16 AM, Mark Hammond wrote: On 28/08/2013 3:30 AM, Gregory Szorc wrote: ... Does anyone else see this libraries-always-rebuild behavior? Not me - although I see just a few small ones - relevant parts of the log: 5:20.54 webapprt.obj 5:21.01 webapprt.cpp 5:21.01 5:21.05 webapprt-stub.exe 5:21.07 MakeNSIS v2.46-Unicode - Copyright 1995-2009 Contributors ... 5:21.27 Output: o:\src\mozilla-git\central2\obj-i686-pc-mingw32\webapprt\win\instgen\webapp-uninstaller.exe ... 5:29.50 nsBrowserApp.obj 5:30.12 nsBrowserApp.cpp 5:30.12 5:30.15 firefox.exe 5:30.32Creating library firefox.lib and object firefox.exp 5:30.32 5:30.35 Embedding manifest from o:/src/mozilla-git/central2/browser/app/firefox.exe.manifest 5:31.38 MakeNSIS v2.46-Unicode - Copyright 1995-2009 Contributors ... 5:32.25 Output: o:\src\mozilla-git\central2\obj-i686-pc-mingw32\browser\installer\windows\instgen\helper.exe ... 5:32.69 MakeNSIS v2.46-Unicode - Copyright 1995-2009 Contributors ... 5:32.90 Output: o:\src\mozilla-git\central2\obj-i686-pc-mingw32\browser\installer\windows\instgen\maintenanceservice_installer.exe and that's it. FYI these are a known consequence[1] of the Build ID being updated every build (and then compiled into the application binary). -Ted 1. https://bugzilla.mozilla.org/show_bug.cgi?id=740359 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Review of changes to Web compat-sensitive prefs in localizations
On Wednesday, February 27, 2013 12:28:43 PM UTC, Axel Hecht wrote: That's rather orthogonal to what you're currently trying to do, but it's also indicating to me that we should remove all of those settings from intl.properties, and just leave accept-lang, and deduce the rest. So how about the parser just accepts a locale value and implements the locale-to-fallback encoding map? Given the numerous problems discovered[1], locale-defaults actually being part of the HTML Standard, and it being available as option to change encourages people to tweak it, I think that would be a better way forward. I wonder if there are similar settings that are in a sense too technical to leave up to localization teams. [1]Recent issues discovered by hsivonen: * https://bugzilla.mozilla.org/show_bug.cgi?id=910163 * https://bugzilla.mozilla.org/show_bug.cgi?id=910165 * https://bugzilla.mozilla.org/show_bug.cgi?id=910169 (bogus value, even) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Review of changes to Web compat-sensitive prefs in localizations
On Wed, Aug 28, 2013 at 3:33 PM, Henri Sivonen hsivo...@hsivonen.fi wrote: If I were starting such a research project, I'd start by testing hypotheses about TLD correlation with legacy encodings. The first thing I'd like to test would be whether it would be an improvement to make builds that have Traditional Chinese as the UI language use gbk (as opposed to big5) as the fallback encoding when browsing content loaded from a .cn domain. To elaborate, we could first have a lookup table from country TLDs to legacy encodings and then only as a second step would use the lookup from the UI localization to legacy encodings for TLDs that don't have a strong country affiliation. So for example, we'd map .cn to gbk, .tw to big5, .ru to windows-1251 and .de, .fr, .se, .nl, .fi etc. to windows-1252, but for .com, .org and such we'd base the guess on the UI locale like today but using a less brittle way of managing the mapping. But anyway, that would be improving the guessing instead of just fixing how the current guessing mechanism is a managed. I don't want better to be a blocker for good here. -- Henri Sivonen hsivo...@hsivonen.fi http://hsivonen.iki.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Review of changes to Web compat-sensitive prefs in localizations
On Wed, Aug 28, 2013 at 3:46 PM, Henri Sivonen hsivo...@hsivonen.fi wrote: On Wed, Aug 28, 2013 at 3:33 PM, Henri Sivonen hsivo...@hsivonen.fiwrote: If I were starting such a research project, I'd start by testing hypotheses about TLD correlation with legacy encodings. The first thing I'd like to test would be whether it would be an improvement to make builds that have Traditional Chinese as the UI language use gbk (as opposed to big5) as the fallback encoding when browsing content loaded from a .cn domain. To elaborate, we could first have a lookup table from country TLDs to legacy encodings and then only as a second step would use the lookup from the UI localization to legacy encodings for TLDs that don't have a strong country affiliation. So for example, we'd map .cn to gbk, .tw to big5, .ru to windows-1251 and .de, .fr, .se, .nl, .fi etc. to windows-1252, but for .com, .org and such we'd base the guess on the UI locale like today but using a less brittle way of managing the mapping. Filed as: https://bugzilla.mozilla.org/show_bug.cgi?id=910211 -- Henri Sivonen hsivo...@hsivonen.fi http://hsivonen.iki.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How to observe selection range within input element
Hi Xulei, I think you can use nsISelectionPrivate::addSelectionListener [1]. You can get nsISelectionPrivate through QueryInterface on nsISelection, which you can get from nsIEditor. Cheers, Jim [1] http://mxr.mozilla.org/mozilla-central/source/content/base/public/nsISelectionPrivate.idl#52 On 8/28/13 5:24 AM, Yuan Xulei(袁徐磊) wrote: Hi all, I'm implementing b2g keyboard/IME api and encounter a problem with the selection range observing. We want to monitor the cursor position or selection range changes in current input element, which is a text input field or a content editable element receiving user's input. The cursor position or the selection range can be changed by 1) key events generated by virtual keyboard, 2) js code, 3) mouse events triggered by user. Currently we listen a pile of events(mousedown, mouseup, input...) to check if the selection range has been changed. It is inefficient and error prone. I wonder if there is a way to monitor the selection range changes from chrome js. Could anyone give me a clue? Thanks. ___ 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: How to observe selection range within input element
Hi Jim and Ehsan, Thank you. It really helps ;-) Mark also show me an example about the usage of selectionListeners, which covers the case of designMode/contentEditable. All the information you provided seems enough to solve my issue :-) Regards, Yuan On 08/28/2013 05:31 PM, Mark Capella wrote: In FF for mobile we use selectionListeners ... won't this work for you? http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/SelectionHandler.js#225 On 08/29/2013 03:24 AM, Ehsan Akhgari wrote: On 2013-08-28 12:22 PM, Jim Chen wrote: Hi Xulei, I think you can use nsISelectionPrivate::addSelectionListener [1]. You can get nsISelectionPrivate through QueryInterface on nsISelection, which you can get from nsIEditor. But note that you can only get the nsIEditor for plaintext controls, that won't work for designMode/contentEditable. Cheers, Ehsan Cheers, Jim [1] http://mxr.mozilla.org/mozilla-central/source/content/base/public/nsISelectionPrivate.idl#52 On 8/28/13 5:24 AM, Yuan Xulei(袁徐磊) wrote: Hi all, I'm implementing b2g keyboard/IME api and encounter a problem with the selection range observing. We want to monitor the cursor position or selection range changes in current input element, which is a text input field or a content editable element receiving user's input. The cursor position or the selection range can be changed by 1) key events generated by virtual keyboard, 2) js code, 3) mouse events triggered by user. Currently we listen a pile of events(mousedown, mouseup, input...) to check if the selection range has been changed. It is inefficient and error prone. I wonder if there is a way to monitor the selection range changes from chrome js. Could anyone give me a clue? Thanks. ___ 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
