Re: padding/margin/border/content highlighting (need platform help)
I just sent a new API proposal to www-style: http://lists.w3.org/Archives/Public/www-style/2013Aug/0605.html It's not particularly difficult to implement, but we need CSSPoint to be implemented first, and that's waiting on Jet and some WebIDL codegen changes in bug 854490. But maybe your needs are just the impetus we need to get this done. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ 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
Re: How to observe selection range within input element
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
Re: nsIDownloadManager replaced by Downloads.jsm
> if you are maintaining an add-on or a Mozilla product that interacts > with downloads, you should look into updating your code to use the new > Downloads.jsm module instead of nsIDownloadManager as soon as possible. We're currently using nsIDownloadManager in Firefox for Metro and will be wanting to adopt Downloads.jsm as soon as possible (likely after our initial preview release). However, although Downloads.jsm itself is importable from toolkit, DownloadsCommon.jsm - which implements a lot of the goodies around it - is not. Looking though it I see only a couple of methods and specific-to-desktop-UI references that would prevent it moving to toolkit. Would you be interested in refactoring a little to enable it to move? I happy to help where I can. Drop into #windev or ping me (sfoster) in #fx-team when you can to discuss. /Sam ___ 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: padding/margin/border/content highlighting (need platform help)
Robert O'Callahan wrote: > On Wed, Aug 28, 2013 at 11:02 PM, Paul Rouget wrote: > > > - 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. > > > > We really need bug 626359 here. That would be ideal. Maybe I can help. If this bug doesn't require too much refactoring and is just about exposing internal info, maybe I can work on it. -- Paul ___ 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 wrote: > On Wed, Aug 28, 2013 at 3:33 PM, Henri Sivonen 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. > 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: Review of changes to Web compat-sensitive prefs in localizations
On Wed, Aug 28, 2013 at 3:33 PM, Henri Sivonen 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:20 PM, Axel Hecht wrote: > On 8/28/13 1:12 PM, Anne van Kesteren wrote: > >> 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 don't think that 'a locale value' is correct. It's not, logically, but it's what we and other browsers currently use in the absence of a better solution. Moving to what Anne suggested plus my elaboration would not make us worse off compared to the status quo. > We should use content languages and not UI language. But from the list of > preferred content languages, we can help the parser. I'm not at all fond of the idea of making *that* obscure piece of configurability having parser behavior implications. If we want to use inputs to the guessing other than the inputs we are using today, that's a research project and not a bug fix project. 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. > It is a bit more tricky in general than we have right now, as for some > users, we'll end up with mismatches between the fallback encodings. We > could just use the first language for which we have one, though. At least > as first step. > I'd rather not block solving the problem raised in this thread on research about how well novel inputs to the guessing process would work. > I don't know which locale-defaults are part of the html spec, before I > read it all, can you elaborate? > See the table under step 9 of http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#determining-the-character-encoding -- 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 8/28/13 1:12 PM, Anne van Kesteren wrote: 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 don't think that 'a locale value' is correct. We should use content languages and not UI language. But from the list of preferred content languages, we can help the parser. It is a bit more tricky in general than we have right now, as for some users, we'll end up with mismatches between the fallback encodings. We could just use the first language for which we have one, though. At least as first step. I don't know which locale-defaults are part of the html spec, before I read it all, can you elaborate? I wonder if there are similar settings that are in a sense too technical to leave up to localization teams. We have a few. We're trying to set them up these days such that garbage values mean en-US default, and provide patches and edits for the others. Axel [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 2:12 PM, Anne van Kesteren wrote: > 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? > Good idea. Bug filed: https://bugzilla.mozilla.org/show_bug.cgi?id=910192 As mentioned in the third paragraph of the bug description, a non-localizable override pref is probably still needed so that the user--not the localizer--can deal with situations like using an en-US build in a non-windows-1252 context. (E.g. because you are a developer and always use en-US builds despite being located in a non-windows-1252 country.) -- 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: padding/margin/border/content highlighting (need platform help)
On Wed, Aug 28, 2013 at 11:02 PM, Paul Rouget wrote: > - 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. > We really need bug 626359 here. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ 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: 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
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
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
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
