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
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
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
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
of the A-team are aware
of this thread, and can answer appropriately.
--
Henrik Skupin
Senior Test Engineer
Mozilla Corporation
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
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
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 necessary
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. There
is
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 on
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
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 do
-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
Senior Test Engineer
Mozilla Corporation
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
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
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
>
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.
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
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
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:
[@
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
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=61ed5c0d64195c58de57489147046aeaf14252d3
>
> is a merge
://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 mailing
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?
Those files are used by test machines for all of our test
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
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
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*
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
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:
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
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
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,
--
Henrik S
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
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
Senior Software Engineer
Mozi
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
nto 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
Thanks for filing those bug
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
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
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-platform mailing list
44 matches
Mail list logo
