https://bugzilla.mozilla.org/show_bug.cgi?id=3D1323185
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=3D1322277
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=3D1332205
Cheers,
--
Henrik Skupin
Senior Software Engineer
Mozilla Corporation
___
dev-platform ma
most
likely by adding support for Taskcluster.
Please also note that nothing of my projects including Mozmill-CI is
using Tinderbox builds. So if something is broken in the future please
file issues for those tools / packages which are not working as expected.
Cheers,
--
Henrik Skupin
after this shutdown via Bugzilla? Or
are those lost?
--
Henrik Skupin
Senior Software Engineer
Mozilla Corporation
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Nick Thomas wrote on 10/21/2015 11:46 AM:
> * to reach older builds you can use
> http://ftp-origin-scl3.mozilla.org/pub/mozilla.org/firefox/
> * please don't get comfortable with that, we'll just be using
> archive.mozilla.org soon
For how long will the ftp-origin-scl3.mozilla.org host be online
Gregory Szorc wrote on 02/17/2016 07:59 PM:
> * You can now define tasks that are neither "build" nor "test" tasks. This
> mechanism is probably where you should place one-off tasks such as linting,
> docs generation, code analysis, etc. See
> https://hg.mozilla.org/integration/mozilla-inbound/rev
Over the last years the formerly known Mozmill tests and now Firefox ui
tests have been located in their own repository. That meant that we
always got regressions due to changes developers have been made in
Firefox. Hunting down those regressions and fixing them was always a
time consuming job. Bes
Matthew N. wrote on 03/01/2016 06:18 PM:
> Could you give an overview of what is tested by this suite and how it
> differs from mochitest-browser-chrome? It seems one difference is that
> some(?) tests run on non-en-US.
So Andrew already told a lot, and just to emphasize here we really do
not w
Mike Hommey wrote on 05/11/2016 05:06 AM:
>> The post states "Mozilla will end support for Firefox on OS X 10.6, 10.7,
>> and 10.8 in August, 2016." This means that we will end support with the
>> Firefox 48 release. i.e. Firefox 48 will not support OS X 10.6-10.8.
>
> That's why the post should h
Hello from Platforms Operations! Once a month we highlight one of our
projects to help the Mozilla community discover a useful tool or an
interesting contribution opportunity.
This month’s project is firefox-ui-tests!
What are firefox-ui-tests?
===
Firefox UI tests are a test sui
Gregory Szorc wrote on 06/28/2016 08:44 PM:
> As of a few minutes ago, when you land commits from MozReview they will be
> pushed to https://hg.mozilla.org/integration/autoland instead of
> https://hg.mozilla.org/integration/mozilla-inbound.
>
> For now, think of integration/autoland as just anoth
Gijs Kruitbosch wrote on 07/01/2016 11:47 PM:
> On 01/07/2016 20:52, Henrik Skupin wrote:
>> I do not see any single merge of autoland to mozilla-central
>
> https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&revision=61ed5c0d64195c58de57489147046aeaf14252d3
>
>
Hi,
Over the last couple of days I noticed a spike of crashes specifically
for our firefox-ui-tests as run on Taskcluster (Linux64, Ubuntu 12.04
docker image). The crashes are completely related to our e10s jobs.
There are a lot of different crash signatures, but mostly these are:
[@ libpthread-2
Hello,
Via bug 1272145 we want to move our existing Firefox-UI tests from
/testing/firefox-ui/ closer to the code which these are testing, so that
the former location only contains the test harness and appropriate unit
tests.
Link to the current set of tests:
https://dxr.mozilla.org/mozilla-centr
Gijs Kruitbosch wrote on 09/01/2016 06:24 PM:
> As I did over IRC, I would like to strongly object to the continued use
> of per-test-type subfolders in our test directories. You can already use
> a specific mach command per test type, and the tests are listed in
> different manifests, *and* th
Matthew N. wrote on 09/02/2016 01:15 AM:
>>> /browser/components/sessionstore/test/firefox_ui/
>>> * update tests:/toolkit/mozapps/update/tests/firefox_ui/
>
> Is there a plan to merge those with
> /toolkit/mozapps/update/tests/marionette? It seems unusual to use both
> when this ne
Gijs Kruitbosch wrote on 09/02/2016 11:37 AM:
> I am not familiar with this bit of our build architecture, but as far as
> I can tell from a quick look it builds bits of the zipfile off the
> objdir. So it collects mochitests from $OBJDIR/_tests/testing/mochitest,
> where (again, AFAICT) things
Gijs Kruitbosch wrote on 09/02/2016 01:22 PM:
> AIUI, if we can run tests directly from a checkout, we no longer need
> the common.tests.zip archive to exist (or at least not to have the tests
> in them), so the problem is moot, no?
I think so. There should not be a need to have to run "mach bu
Gijs Kruitbosch wrote on 09/02/2016 01:22 PM:
> AIUI, if we can run tests directly from a checkout, we no longer need
> the common.tests.zip archive to exist (or at least not to have the tests
> in them), so the problem is moot, no?
Those files are used by test machines for all of our test suite
L. David Baron wrote on 09/04/2016 10:02 AM:
> Recently, sheriffing practices have changed so that intermittent
> failure bugs that show up in different tests now have a separate
> bugzilla bug for each test they occur in. This causes:
>
> 1. a large number of rarely-occurring bugs -- enough th
keep that rate for a while now to make the sheriffs
happy.
--
Henrik Skupin
Senior Software Engineer
Mozilla Corporation
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
.
--
Henrik Skupin
Senior Software Engineer
Mozilla Corporation
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Henrik Skupin wrote on 01/09/16 17:37:
After a longer time without a response I would like to give a follow-up
on where we stand at the moment and what the future will be for those tests.
But first, I want to say thanks to everyone who participated in this
thread. The received feedback was very
package name was used.
For external code you will have to update your package dependencies once
the code has been landed and the new package released to PyPI. If you
don't do so, no further updates will be available via PyPI.
In case you have questions please let us know.
Thanks,
--
exporting the following variable:
export PYTHONDONTWRITEBYTECODE=1
--
Henrik Skupin
Senior Software Engineer
Mozilla Corporation
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
switch over to use these new tests but I expect that to
>> be pretty straightforward.
>
> Was Marionette considered? From what little I know (jgriffin and others
> can correct me), Marionette seems like the logical base for this test suite.
Adding the tools mailing list, so that m
As I have read [1] that Google will drop support for 32bit mode of
Chrome with the upcoming 39 release in November. I wonder what our
support plans for 32bit mode on OS X look like. Is it something we want
to keep, to allow e.g. users of Chrome, who cannot run a 64bit version
of Chrome, to switch o
Robert Strong wrote on 09/19/2014 06:59 PM:
> Regarding dropping support, Silverlight on Mac does not support 64 bit and
> we run it using 32 bit. So at the very least we will need html5 for sites
> like Netflix before we can drop 32 bit support on OS X.
I see. So I will investigate what's necessa
Robert Strong wrote on 09/22/2014 09:50 AM:
>> I see. So I will investigate what's necessary to get those builds
> running in
>> parallel via Mozmill CI.
>
> Specifically, the 32bit plugin-container and libraries that it loads.
The one and only plugin we make use of for tests is Adobe Flash. The
Robert Strong wrote on 09/22/2014 11:07 AM:
Hi Robert,
> All of the major changes for Mac v2 signing have landed on the Oak branch.
> This will allow us to test installing and updating before landing on
> mozilla-central.
[..]
>
> If no serious issues are found we are hoping to be able to land o
Robert Strong wrote on 10/01/2014 06:22 AM:
Hi Robert,
> If you find any bugs that you believe are due to these changes please file
> a new bug under toolkit -> application update and we'll take it from
> there.
Thanks for the update. Beside the crasher bug we found, and which has
been fixed we
ISHIKAWA,chiaki wrote on 10/11/2014 03:22 PM:
Hi,
> But then I realize that the current dialog mechanism may not have
> such an identifier. (Maybe we can use the string or part of the string
> that is shown in the dialog as a key to distinguish different dialogs?
> Of course, change to existing d
he individual topics I might
follow-up with separate blog posts and a more detailed description of
work happening in those areas.
Please let us know if you have questions or want to participate in that
work. I'm always up for mentoring people from the community.
Best,
--
Henrik Skupin
Andrew Halberstadt wrote on 05/13/2015 04:24 PM:
> I thought thunderbird was using a very out-of-date version of mozmill
> which was already unmaintained anyway? Or did you already upgrade to the
> latest version?
Yes, its a very outdated version of Mozmill from the hotfix-1.5 branch,
which we
binaries into a development build... why?" But there's really no reason we
> can't do that in automation so I've filed
> https://bugzilla.mozilla.org/show_bug.cgi?id=15175323 for these things.
This is actually: https://bugzilla.mozilla.org/show_bug.cgi?id=1517533
Th
Nika Layzell wrote on 09.08.19 19:33:
>Wait for document loads to complete before trying to run code inside the
>target window, as a process switch may occur after the frame or browser is
>created. For frames in content, this usually means waiting for the load
>event.
While workin
ll be available
for users of Mercurial? When I use this option I get:
> NotImplementedError: Mercurial revisions can't be submitted without
Arcanist
Thanks
--
Henrik Skupin
Senior Software Engineer
Mozilla Corporation
___
dev-platfor
glob wrote on 23.10.19 17:56:
> It's available now - make sure you're running the latest version by
> running `moz-phab self-update`.
That's what I did yesterday, but as it looks like the self-update
actually didn't update my version to the latest MozPhab-0.1.55. I will
check soon with this versi
Hi all,
I want to start with crashtests for webrtc crashes which have been fixed
recently. Sadly this feature is disabled on mozilla-central and
mozilla-aurora. So I would have to set two preferences to get access to
all the features. Now I see that crashtests are getting run through the
reftest f
Bobby Holley wrote on 10/15/12 2:12 PM:
> Now that bug 792029 has landed, you should be able to use
> SpecialPowers in crashtests.
Wow, great response time and great answer! Thank you a lot Bobby!
--
Henrik
___
dev-platform mailing list
dev-platform@li
Ted Mielczarek wrote on 10/15/12 2:16 PM:
> The reftest manifest format (which crashtest uses, since crashtests
> run in the reftest harness) has explicit support for setting
> preferences per-test:
> http://mxr.mozilla.org/mozilla-central/source/layout/tools/reftest/README.txt#160
Sounds good. I
L. David Baron wrote on 10/15/12 4:31 PM:
> There's a reviewed patch in
> https://bugzilla.mozilla.org/show_bug.cgi?id=788967 that adds
> support for this, but apparently it had failures on try.
Exactly what I need. Will watch when it lands. Thanks!
--
Henrik
___
current documentation revamp project for test frameworks.
Thanks a lot,
--
Henrik Skupin
Software Engineer in Test
Mozilla Corporation
--
Henrik
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev
Justin Lebar wrote on 10/25/12 10:06 AM:
> I'd probably be a lot more sympathetic to this proposal if I
> understood in a concrete way how making my life a little harder here
> would make your life a little easier. What problem exactly are you
> trying to solve?
Good points. So let me give one e
Henrik Skupin wrote on 10/25/12 9:48 AM:
> With this post we want to get feedback from module owners and how they
> feel with such a reorganization of the tests. If we agree all on it I
> would like to go ahead and submit patches in smaller chunks most likely
> on a per module basis.
Hi,
A crashtest for WebRTC requires to reload the current page. So that can
be done by window.location.reload(). Sadly this will cause an infinite
loop when run in the automation. So which practice do we have to set a
flag once the window has been reloaded once? Are there any guides how to
do it?
Kyle Huey wrote on 11/15/12 12:26 AM:
> Can you use an iframe?
I tried and it would work if we wouldn't crash in another area. So using
an iframe is certainly another crashtest. But thanks for the information!
--
Henrik
___
dev-platform mailing list
d
Kevin Gadd wrote on 11/15/12 12:37 AM:
> Increment a value in localStorage?
That's what I have used now and which works great. Thanks Kevin!
--
Henrik
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-p
47 matches
Mail list logo
