On 2017/06/16 6:47, Mike Hommey wrote:
On Thu, Jun 15, 2017 at 04:51:48PM -0400, Ben Kelly wrote:
On Thu, Jun 15, 2017 at 4:37 PM, Nathan Froyd <nfr...@mozilla.com> wrote:
On Thu, Jun 15, 2017 at 2:02 PM, Brendan Dahl <bd...@mozilla.com> wrote:
Headless will run less of the platform specific widget code and I don't
recommend using it for platform specific testing. It is targeted more at
web developers and testing regular content pages. There definitely will
be
cases where regular pages will need to exercise code that would vary per
platform (such as fullscreen), but hopefully we can provide good enough
emulation in headless and work to have a consistent enough behavior
across
platforms that it won't matter.
Would it be feasible to use headless mode for mochitests (or reftests,
etc. etc.)? I know there are probably some mochitests which care
about the cases you mention above (e.g. fullscreen), but if that could
be taken care of in the headless code itself or we could annotate the
tests somehow, it would be a huge boon for running mochitests locally,
or even in parallel. (We already have some support for running
reftests/crashtests in parallel.)
There are some tests which fail if the "screen" is not a particular size.
Those might be a problem as well.
The worse offenders are the tests that want focus.
Mike
So modal dialog is bad.
Now my memory is coming back. I added an error dialog processing to a
particular error condition which was not explicitly flagged to the user
at run time. I think the user is best notified that such an error
condition exists (I think it was an I/O error or something).
The code failed under xpcshell test because the window (or something
similar) was not available when it tried to produce the modal dialog on
encountering the error condition created artificially under xpcshell test.
So I changed the code to put something in the error console instead of
producing the error dialog, which definitely is not easy to handle in
headless mode.
Then the code failed the xpcshell test because, it seems to me, that
xpcshell test suite framework fails a unit test if it detects something
is put into error console. Oh well.
So finally I changed the code to print something to stderr under linux
in full DEBUG build (won&t work under Windows.). Not ideal but at least
I could check the error processing worked internally, but the user was
kept in the dark because no visible feedback was produced via GUI when a
serious I/O error occurred.
However, now that I know I can suppress the modal error dialog in
headless mode by checking a global flag, I have a chance of passing
xpcshell test. Interesting.
TIA
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
