Skip to content
GitLab
  1. 22 Feb, 2018 2 commits
  3. 15 Feb, 2018 1 commit
  5. 22 Feb, 2018 5 commits
  7. 21 Feb, 2018 1 commit
  9. 14 Feb, 2018 1 commit
    • Brendan Dahl's avatar
      Bug 1434077 - Inline indicators overlay. r=Paolo · aa526601
      Brendan Dahl authored 
      This is part of the work to remove XUL overlays. The overlay was originally
created to help startup performance, but inlining the overlay seems to
no longer have detrimental effects to performance and is more straightforward.

MozReview-Commit-ID: 7sfVel6qvgv

--HG--
extra : rebase_source : b6311cf1fb98851b4f4203c314ae9ecc8160d766
      aa526601
  11. 06 Feb, 2018 1 commit
    • Brendan Dahl's avatar
      Bug 1434077 - Inline downloads overlay. r=Paolo · bd38c4bf
      Brendan Dahl authored 
      This is part of the work to remove XUL overlays. The overlay was originally
created to help startup performance, but using a hidden panel instead seems to
have no detrimental effects to performance and is more straightforward.

MozReview-Commit-ID: JlWcZEhPXyH

--HG--
rename : browser/components/downloads/content/downloadsOverlay.xul => browser/components/downloads/content/downloadsPanel.inc.xul
extra : rebase_source : 60a9fec344b1e346594015cd36947fe1779257a7
      bd38c4bf
  13. 22 Feb, 2018 2 commits
    • Josh Matthews's avatar
      servo: Merge #20106 - Add font cache debugging to isolate cause of IPC... · a6365edb
      Josh Matthews authored 
      servo: Merge #20106 - Add font cache debugging to isolate cause of IPC failures in CI (from jdm:font-thread-shutdown-debug); r=emilio

This should help us better understand the actual underlying cause of frequent CI failures like #13509. In particular, we will be able to state with confidence whether an IPC message is being dropped while the font cache thread is still alive, or whether the dropped sender was in a message that was in the queue after the font cache thread was shutdown.

---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] There are tests for these changes

Source-Repo: https://github.com/servo/servo
Source-Revision: 267f9db314acc6641c896a595a24fbb18da74459

--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : ee504c86a77be8912548205244b895ad542401c0
      a6365edb
    • Andreea Pavel's avatar
      Backed out changeset d8ffc9e58ff1 (bug 1432232) for mochitest devtools... · 9470b1bf
      Andreea Pavel authored 
      Backed out changeset d8ffc9e58ff1 (bug 1432232) for mochitest devtools failures at devtools/client/webconsole/new-console-output/test/fixtures/stub-generators/browser_webconsole_check_stubs_console_api.js on a CLOSED TREE
      9470b1bf
  15. 09 Feb, 2018 1 commit
  17. 08 Feb, 2018 2 commits
  19. 21 Feb, 2018 1 commit
  21. 06 Feb, 2018 1 commit
  23. 22 Feb, 2018 2 commits
    • Jon Leighton's avatar
      servo: Merge #20051 - Disallow mutating the internals of TextInput (from... · 7641a19d
      Jon Leighton authored 
      servo: Merge #20051 - Disallow mutating the internals of TextInput (from jonleighton:prevent-invalid-selections); r=jdm

The TextInput::assert_ok_selection() method is meant to ensure that we
are not getting into a state where a selection refers to a location in
the control's contents which doesn't exist.

However, before this change we could have a situation where the
internals of the TextInput are changed by another part of the code,
without using its public API. This could lead to us having an invalid
selection.

I did manage to trigger such a situation (see the test added in this
commit) although it is quite contrived. There may be others that I
didn't think of, and it's also possible that future changes could
introduce new cases. (Including ones which trigger panics, if indexing
is used on the assumption that the selection indices are always valid.)

The current HTML specification doesn't explicitly say that
selectionStart/End must remain within the length of the content, but
that does seems to be the consensus reached in a discussion of this:

https://github.com/whatwg/html/issues/2424

The test case I've added here is currently undefined in the spec which
is why I've added it in tests/wpt/mozilla.

Source-Repo: https://github.com/servo/servo
Source-Revision: f6463c89d50b0ebc377bfe10bd0ffe0c59dd84ca

--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : a8ee624291af3d58b8126cd067ea9f7292bfca6b
      7641a19d
    • Ursula Sarracini's avatar
      Bug 1440389 - Invalidate Pocket cache when blocking a link r=Mardak · 311d093d
      Ursula Sarracini authored 
      MozReview-Commit-ID: Beh7bGKOizJ

--HG--
extra : rebase_source : 1e20ceed8f923fb2c2407b755d6d84ab5a81cb6d
      311d093d
  25. 14 Feb, 2018 2 commits
  27. 15 Feb, 2018 1 commit
    • Michael Ratcliffe's avatar
      Bug 1437849 - Enable... · 62aa51ed
      Michael Ratcliffe authored 
      Bug 1437849 - Enable browser_console_hide_jsterm_when_devtools_chrome_enabled_false.js in new frontend r=Honza

This whole test neede rewriting. Beginning with the new console frontend we no longer block the object inspector in the browser console when `devtools.chrome.enabled === false`.

MozReview-Commit-ID: 9H5FvIbkYzk

--HG--
rename : devtools/client/webconsole/new-console-output/test/mochitest/browser_console_hide_jsterm_when_devtools_chrome_enabled_false.js => devtools/client/webconsole/new-console-output/test/mochitest/browser_jsterm_hide_when_devtools_chrome_enabled_false.js
extra : rebase_source : a649b20be57d394ff24c5f2bafaf1d2b8687ff40
      62aa51ed
  29. 14 Feb, 2018 1 commit
  31. 22 Feb, 2018 6 commits
    • arthur.iakab's avatar
      Backed out 3 changesets (bug 1428816) for Browser Chrome failures on... · e5eabd78
      arthur.iakab authored 
      Backed out 3 changesets (bug 1428816) for Browser Chrome failures on browser/base/content/test/static/browser_misused_characters_in_strings.js on a CLOSED TREE

Backed out changeset 31e12673218b (bug 1428816)
Backed out changeset a6e7a7b21cf3 (bug 1428816)
Backed out changeset 0d00eabc8b83 (bug 1428816)
      e5eabd78
    • Emilio Cobos Álvarez's avatar
      Bug 1439155: Be consistent about what does readonly apply to. r=smaug · 8010ae3a
      Emilio Cobos Álvarez authored 
      MozReview-Commit-ID: 4NiDe7pUzGa

--HG--
extra : rebase_source : 97c42c12cbeffaf360c9b91f4ee8bc7b95e4e48e
      8010ae3a
    • Nicolas Chevobbe's avatar
      Bug 1432232 - Implement prefix support in new console frontend; r=bgrins. · c81c7b13
      Nicolas Chevobbe authored 
      The prefix property was already on the packet, so all we had to
do was to support it. Which means:
 - retrieve the property in the packet and pass it to the message
 - when prefix exists, add a dom element with a custom style
 - search in prefix when filtering.

We add a couple of mocha tests with a stub packet to make sure we
handle those cases like we should.

MozReview-Commit-ID: KFkt685AdfE

--HG--
extra : rebase_source : 71f13c07921b1d60df1a0c113d1e3fb440923ec2
      c81c7b13
    • Marco Zehe's avatar
      Bug 1439925 - Make the breadcrumbs container a proper toolbar for screen... · 9d7a5b5f
      Marco Zehe authored 
      Bug 1439925 - Make the breadcrumbs container a proper toolbar for screen readers, and fix the localization include for its label, r=gl

MozReview-Commit-ID: 14mRxfE2ucx

--HG--
extra : rebase_source : 23dc29302032cf55c8bb696df9815369a59e808e
      9d7a5b5f
    • Jon Leighton's avatar
      servo: Merge #20021 - Lazy load fonts in a FontGroup (from... · 62986df7
      Jon Leighton authored 
      servo: Merge #20021 -  Lazy load fonts in a FontGroup (from jonleighton:lazy-font-group); r=mbrubeck,glennw

 Lazy load fonts in a FontGroup

The first commit message explains this so I'll just copy it here:

---

This is a step towards fixing #17267. To fix that, we need to be able to
try various different fallback fonts in turn, which would become
unweildy with the prior eager-loading strategy.

Prior to this change, FontGroup loaded up all Font instances, including
the fallback font, before any of them were checked for the presence of
the glyphs we're trying to render.

So for the following CSS:

    font-family: Helvetica, Arial;

The FontGroup would contain a Font instance for Helvetica, and a Font
instance for Arial, and a Font instance for the fallback font.

It may be that Helvetica contains glyphs for every character in the
document, and therefore Arial and the fallback font are not needed at
all.

This change makes the strategy lazy, so that we'll only create a Font
for Arial if we cannot find a glyph within Helvetica. I've also
substantially refactored the existing code in the process and added
some documentation along the way.

---

I've added some tests in the second commit, but it required quite a bit of gymnastics to make it possible to write such a test. I'm not sure if the added complexity to the production code is worth it?

On the other hand, having this infrastructure in place may be useful for testing future changes in this area, and also possibly brings us a step closer to extracting a library as discussed in #4901. (What I mean by that is: it reduces coupling between `FontCacheThread` and `FontContext` -- the latter would have a place in such a library, the former wouldn't.)

Source-Repo: https://github.com/servo/servo
Source-Revision: f48dce120dddd8e3d585cfc8bc221faa2726bf6b

--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : fb8733e63bb69d941051bf4aff8a86c396c85f8e
      62986df7
    • Matthew Noorenberghe's avatar
      Bug 1438702 - Skip test_credit_card_autofill_section when CC autofill is disabled. r=jaws · 05f00ac1
      Matthew Noorenberghe authored 
      MozReview-Commit-ID: B1qa9BhIa05

--HG--
extra : rebase_source : 90c896bb1ebe84b687cc1b1d1698542fd0c69aa0
      05f00ac1
  33. 21 Feb, 2018 1 commit
  35. 09 Feb, 2018 1 commit
  37. 08 Feb, 2018 2 commits
  39. 22 Feb, 2018 6 commits