On 23 Oct 2019 22:24, Emma Humphries wrote:
Will this make it easier for non-staff contributors to get their change
sets reviewed and landed?
What else should we be doing for that.
I have some ideas I'm working on for views in Bugzilla to help with that so
that contributors can see what's
Hi all,
I'm not sure whether Thunderbirds are different, but the issue is that
(on Windows) xul.dll is constantly relinked although there haven't been
any changes to C++ or RS files. Log below.
Oh, you can also see some ugly hunspell warnings that have crept in a
while ago.
Jörg.
$ mach
On 30 Jul 2019 13:50, ISHIKAWA,chiaki wrote:
What is the version of clang used on tryserver?
The same as on the local machine? For Windows I get:
$ ../.mozbuild/clang/bin/clang --version
clang version 8.0.0 (tags/RELEASE_800/final 356365)
Target: x86_64-pc-windows-msvc
Thread model: posix
On 12/04/2019 10:04, Makoto Kato wrote:
But I am already triage owner of some components (editor, i18n and
GeckoView's input), so I hope that anyone takes ownership of spellchecker
for triage/module. If no one handles it, I can handle triage process as
temporary due to low volume until new
On 06/02/2019 21:42, Kim Moir wrote:
On February 28 Bugzilla review flags will be disabled for Firefox and other
mozilla-central products and components. From this point forward, all
reviews of code changes to mozilla-central should be conducted in
Phabricator. Tasks that have been identified as
Hi all,
an unrelated discussion made me aware that the master password cipher
strength bug[1] is still open. Any plans to tackle that?
Other software uses strong AES algorithms for their "password
collections". Would it be hard to follow?
Jörg.
[1]
On 10/07/2018 22:29, David Major wrote:
Bug 1443590 is switching our official Windows builds to use clang-cl
as the compiler.
Please keep an eye out for regressions and file a blocking bug for
anything that might be fallout from this change. I'm especially
interested in hearing about the
On 06/11/2017 18:46, Justin Wood wrote:
Now with Taskcluster the start time is anchored in UTC so doesn't move
along with Daylight Savings, currently anchoring at 10am and 10pm UTC.
Is that connected to merge times? Should the merges into M-C be done
just before those two times?
Right now
On 02/11/2017 00:41, Nicholas
Nethercote wrote:
1) Remove the defaults/preferences directory support for extensions. This
is a feature that was used by legacy extensions but is not used by
WebExtensions.
Is that the facility that legacy extensions can have
Hi,
as part of the Thunderbird Xpcshell test suite we're running many M-C
Xpcshell tests. On Mac debug we're seeing:
TEST-UNEXPECTED-FAIL | dom/push/test/xpcshell/test_permissions.js |
xpcshell return code: -11
PID 6475 | Assertion failure: 0 == rv, at
On 22/07/2017 21:42, Enrico Weigelt, metux IT consult wrote:
Even hg clone runs for hours.
Best to use a bundle:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Source_Code/Mercurial/Bundles
Jörg.
___
dev-platform mailing list
On 20/07/2017 17:34, Kris Maglione wrote:
Please see replies elsewhere in this thread. Seamonkey and Thunderbird
do use the old signature code that we're talking about removing.
Thanks Kris.
As you know, TB and SM are maintained mainly by volunteers. We have to
interface with all areas of
As the removal of XUL add-ons is imminent, I asked the author of the
"Show Parent Folder" add-on, that shows a much needed "Parent Folder"
column in the bookmarks window, whether his add-on would be ported to
the new scheme and his answer was:
'NO' unfortunately. AFAIK, Webextensions do not
On 28/03/2017 17:58, Zbigniew Braniecki (Gandalf) wrote:
We just landed the final change that culminates the 3 month long major
refactor of how Gecko handles language selection [0] (pending
autoland->central).
Nice job!
On top of that, we gained an additional helper API for retrieving
On 16.03.17 09:08, Boris Zbarsky wrote:
We should try marking nsIOutputStream builtinclass on trunk right now.
As far as I can tell, this should just work.
No adverse effects on Thunderbird, I hope:
https://dxr.mozilla.org/comm-central/search?q=nsIOutputStream=false
As far as I can see we
On 03/03/2017 12:10, Gervase Markham wrote:
Or if you just want to see it, mouse over and read the tooltip.
The requirement explicitly stated was: I'd also like to see the full
date and hour in a *copyable* form.
I raised some usability issues in bug 1344233 as requested.
Jörg.
On 02/03/2017 16:06, David Lawrence wrote:
Thanks for the feedback. Please file this as a bug if you haven't
already, outlining the proposed workflow change. I could see how
automatically exposing the milestone form field when resolving a bug
could be useful for a lot of people.
Yes, maybe
On 01/03/2017 21:47, David Lawrence wrote:
Today, the BMO Team changed the default bug view to the new modal
view that has been in development for a while.
I like the fact that you can now change the Product in one step.
Sadly when resolving a bug, there's now an additional click
On 26/10/2016 09:50, Masayuki Nakano wrote:
nsIHTMLEditor.setDocumentTitle() is used only by Thunderbird, Mail and
Composer of SeaMonkey. Additionally, they can set editable document
title with |document.title = "foo";|.
No problem. Thanks for the heads-up.
Already addressed in
On 23/08/2016 06:28, Nicholas Nethercote wrote:
I see that I've caused several Thunderbird breakages with the changes
I've been making. I apologize for not giving you advance warning about
this.
Since I'm the guy who was, as Kent said, "forced [...] to drop
everything", I think some warning
Sorry for joining this thread after 77 previous posts, which,
admittedly, I haven't all read.
Also excuse me if I'm asking something that has been asked/answered
before. I tried looking for keywords in the messages (update, index,
refresh).
Simple question: How often is DXR refreshed from,
Sorry about the noise. Seems to be related to an sqlite update. We're
looking at it in bug 1252937. Jorg K.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Hello all,
Instead of searching for hours, I though I'd ask for help:
Thunderbird tests don't run since the first of March. Something landed here
https://treeherder.mozilla.org/#/jobs?repo=mozilla-central=8ef94be995a4
- Tue Mar 1, 11:59:06
On 3/01/2016 15:19, Jesper Kristensen wrote:
Mozilla should officially maintain the en-US dictionary on
https://addons.mozilla.org/en-US/firefox/language-tools/ , like
Mozilla officially maintains the language packs.
I've raised https://bugzilla.mozilla.org/show_bug.cgi?id=1236375.
BTW, I
On 3/01/2016 15:19, Jesper Kristensen wrote:
Creating a second add-on with a different extension ID will not fix
things, only make them worse. Now users have two en-us dictionaries to
choose from, with no information telling which one is better. All
existing users are stranded on the old
On 2/01/2016 12:37, Pascal Chevrel wrote:
Le 02/01/2016 12:07, Jörg Knobloch a écrit :
It is very unfortunate that this add-on maintained by "jooliaan" is so
badly out of date. I don't know how to contact the author. I suggest
that he synchronise the add-on with the Mozilla mainta
On 3/01/2016 19:11, Jesper Kristensen wrote:
I don't think it is that special. Some Firefox locales other than en-US
ship with built in dictionaries. For those, the add-on could be derived
from the source of the Firefox locale.
It is special since Mozilla maintain the dictionary, they don't
On 2/01/2016 10:53, Jesper Kristensen wrote:
The en-US dictionary for localized Firefox was last updated in March
2013 according to
https://addons.mozilla.org/da/firefox/addon/united-states-english-spellche/versions/
It is very unfortunate that this add-on maintained by "jooliaan" is so
On 2/01/2016 12:07, Jörg Knobloch wrote:
Furthermore we're planning to improve the dictionary in collaboration
with SCOWL by recovering some/most of the 5670 words removed by bug
1137544 in May 2005
There is always a mistake, spellcheck doesn't detect. ;-(
Make that May *2015*.
Jorg K
On 30/12/2015 10:20, Jörg Knobloch wrote:
I can't understand how the current system could manage SCOWL removals
yet not remove words Mozilla specifically added. How does it know that a
word came from SCOWL and can be removed or it didn't come from SCOWL and
should be maintained?
Oops, I
On 30/12/2015 01:46, Ehsan Akhgari wrote:
First things first, let's correct something here. We do _not_ maintain
three word lists. We maintain one list: the list of words that the
Firefox spellchecker accepts.
I know I sound like a broken record: I suggested to change the process
and maintain
On 29/12/2015 21:54, Ehsan Akhgari wrote:
They are not Mozilla special words. They are words that we want to add
to our spell checking dictionary that don't exist in the upstream SCOWL
word list.
In bug 1235506 I suggest to maintain three lists:
1) proper names of which we have about 12.000.
On 29/12/2015 18:23, Ehsan Akhgari wrote:
I see no reason for Mozilla to stop maintaining and shipping the en-US
dictionary.
Agreed. But we should take a different approach. I disagree that the
current process is working well since it carries forward legacy errors.
I must admit that my
On 28/12/2015 20:31, Jörg Knobloch wrote:
For example, the Mozilla dictionary only knows "zucchini", whereas the
add-on dictionary also knows "Zulu" and other words starting with
"zu". I'd hate to think that we'd need to create 7265 bugs to add all
the mis
On 28/12/2015 23:45, Mike Hommey wrote:
We're not investing time and effort, that's the core problem... we're
essentially letting it rot, without updating with newer upstream
versions, which is time and effort on its own.
Well,
Recently I was browsing some bugs in "Core::Spelling checker" and much
to my surprise found four bugs where people complained about wrong or
missing words in the en-US dictionary. There were two bugs where people
complained about words in the German and the French dictionaries.
The German and
On 29/12/2015 00:15, Mike Hommey wrote:
Because, we have, in fact, imported a new upstream version. The drop in
size comes from bug 1137544, which is an upstream import...
Hmm, something went wrong from here
On 29/12/2015 08:28, Philip Chee wrote:
Time to fork
I disagree. It's time to get it right:
https://bugzilla.mozilla.org/show_bug.cgi?id=1235506
Jorg K.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On 30/11/2015 16:38, Henri Sivonen wrote:
Are there any objections to removing the ISO-2022-JP-2 functionality
from mozilla-central?
Hello,
I am currently in the process of repairing long-standing issues with CJK
e-mail in general and Japanese e-mail using ISO-2022-JP in particularm
see
Has a decision been made or was this all just NATO (No Action, Talk
Only)?
Jorg K.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On 27/10/2015 03:32, Ehsan Akhgari wrote:
Over the years I have gained a *ton* of experience in code that
interfaces with both Firefox and Thunderbird/SeaMonkey. I can't really
think of a single instance where I made a change in that code and it
broke something in Thunderbird and the breakage
Hi all,
I have followed the discussion with interest and I'd like to suggest to
focus on the practical aspect.
The facts are:
Thunderbird, SeaMonkey and Calendar/Lightning are Mozilla products (with
a significant number of users).
They are maintained by dedicated communities.
(Kent has
On 22/10/2015 02:49, Ehsan Akhgari wrote:
I think it's
time for me to step down as the owner of editor/.
Sad to hear and thank you for your work.
Is there a list of unowned modules? Recently I heard that the serializer
code is also practically unowned. That's located in dom/base.
What is
On 27/09/2015 23:22, Ehsan Akhgari wrote:
Thanks! I submitted fixes for a number of these.
Great. I saw these bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=1208905
https://bugzilla.mozilla.org/show_bug.cgi?id=1208904
https://bugzilla.mozilla.org/show_bug.cgi?id=1208903
On 3/09/2015 12:44, Florian Quèze wrote:
The solution I would like to see implemented (and I'm willing to help)
is automatic detection of the language.
Nice idea.
I'd like to clean-up the current behaviour first in
https://bugzilla.mozilla.org/show_bug.cgi?id=1200533 so we have a solid
base
On 2/09/2015 07:17, lalo.mart...@gmail.com wrote:
To put it simply, if I select a language via the context menu, it should still
be there next time I visit the same site; it's the intended behaviour for the
current code, and even if I don't think it's ideal, it's currently broken, and
I don't
On 2/09/2015 12:24, Robert O'Callahan wrote:
The patch in bug 717433 just seemed like an especially clear
improvement.
Agreed. This was the nastiest problem that affected the most users and
had the most obvious fix.
As detailed earlier in the thread, there is another puzzling issue that
On 1/09/2015 16:01, Ehsan Akhgari wrote:
I suppose you can find them on #fx-team.
Just for the record from IRC:
jorgk:
Hi, #fx-team. I had this discussion with Ehsan
https://groups.google.com/forum/#!topic/mozilla.dev.platform/Et02D8Mk2d0
on improving the spell checking in Firefox.
Hi all,
I hope we can at least agree on fixing the problems with the current
behaviour.
I raised bug https://bugzilla.mozilla.org/show_bug.cgi?id=1200533 for that.
The clear order of priorities that will be established will be:
1) content preference, not ignoring an "en-GB" setting on a plain
On 1/09/2015 16:01, Ehsan Akhgari wrote:
The fundamental issue is that different people have different needs,
and there is also the information that the website gives us which we
need to take into account somehow. You are describing what _you_
would like to see.
Actually: No. I was
On 31/08/2015 08:12, Anne van Kesteren wrote:
HTML4 is long obsolete.
OK, the HTML5 definition is here:
http://www.w3.org/TR/html5/dom.html#the-lang-and-xml:lang-attributes
It comes to the same result.
4) Fall-back options including the locale and others.
"Polyglot users" unset
On 31/08/2015 17:18, Ehsan Akhgari wrote:
Just wanting to reiterate that the problem is not as big as you claim
it is. We did not break Firefox for "single language users".
If you take a good look at the fallback processing in
editor/composer/nsEditorSpellCheck.cpp, you will notice that it
Hi all,
Today I would like to discuss a change I'd like to make to the way the
spell checking language is selected for text input (editor) fields.
Before I get to my proposal, we need to take a little stroll down memory
lane.
In the good old days, when setting the spell check language in a
53 matches
Mail list logo
