1. 17 Jun, 2020 1 commit
  2. 27 May, 2020 1 commit
  3. 26 May, 2020 1 commit
  4. 05 May, 2020 2 commits
  5. 27 Apr, 2020 1 commit
  6. 28 Apr, 2020 3 commits
    • Csoregi Natalia's avatar
      Backed out 30 changesets (bug 1556556, bug 1631568) for multiple mochitest failures. CLOSED TREE · b073baab
      Csoregi Natalia authored
      Backed out changeset edd529f7a9c5 (bug 1631568)
      Backed out changeset 1cc0881e244b (bug 1631568)
      Backed out changeset ed3c1e85d5e3 (bug 1556556)
      Backed out changeset 38ffc6215bbf (bug 1556556)
      Backed out changeset 03c2c25d8023 (bug 1556556)
      Backed out changeset 9c717eb067b8 (bug 1556556)
      Backed out changeset 98e26bc98b85 (bug 1556556)
      Backed out changeset 05a6a581e755 (bug 1556556)
      Backed out changeset 867946cf05bb (bug 1556556)
      Backed out changeset 20d72a334530 (bug 1556556)
      Backed out changeset 2c62e61d9054 (bug 1556556)
      Backed out changeset 62a223d057d2 (bug 1556556)
      Backed out changeset 2c5d55a1f0b1 (bug 1556556)
      Backed out changeset 700447945b4e (bug 1556556)
      Backed out changeset 93190ae4f5ff (bug 1556556)
      Backed out changeset a7bd34d961bb (bug 1556556)
      Backed out changeset fccd1d3c7189 (bug 1556556)
      Backed out changeset 24056e47183d (bug 1556556)
      Backed out changeset 204881474cc1 (bug 1556556)
      Backed out changeset 387320881876 (bug 1556556)
      Backed out changeset be8f5eb58460 (bug 1556556)
      Backed out changeset 629c58a9166b (bug 1556556)
      Backed out changeset 4312b2b5dda8 (bug 1556556)
      Backed out changeset d11dbf6403a5 (bug 1556556)
      Backed out changeset 95c54c023779 (bug 1556556)
      Backed out changeset 80fcb7e71188 (bug 1556556)
      Backed out changeset d75a4ecb0d47 (bug 1556556)
      Backed out changeset 903c4de34e7a (bug 1556556)
      Backed out changeset f15334a3e803 (bug 1556556)
      Backed out changeset 9553e99137ea (bug 1556556)
      b073baab
    • Botond Ballo's avatar
      Bug 1556556 - Convert mRefPoint to visual coordinates for synthesized events. r=tnikkel · 29e3ec7e
      Botond Ballo authored
      As part of this change, PresShell::mMouseLocation in stored visual coordinates.
      
      Differential Revision: https://phabricator.services.mozilla.com/D69640
      29e3ec7e
    • Botond Ballo's avatar
      Bug 1556556 - Remove some cruft related to handling the resolution in non-e10s setups. r=tnikkel · 5e9a66a3
      Botond Ballo authored
      Prior to this bug, it was necessary to handle non-e10s specially, because the
      resolution was being unapplied at the process boundary, and in non-e10s there
      was no process boundary.
      
      The remaining patches in this bug move the resolution unapplication away from
      the process boundary in all cases, making special handling for non-e10s
      unnecessary.
      
      Differential Revision: https://phabricator.services.mozilla.com/D68273
      5e9a66a3
  7. 17 Apr, 2020 1 commit
    • Emilio Cobos Álvarez's avatar
      Bug 1449522 - Remove nsIEditorStyleSheets. r=masayuki,m_kato · 31821e1f
      Emilio Cobos Álvarez authored
      Users have much better, easier alternatives, like
      DOMWindowUtils.{loadSheetUsingURIString,removeSheet}, which we use to
      replace the only caller that exists in mozilla-central (the editor
      element, which loads EditorOverride.css).
      
      This allows to clean up the style system and editor. There are other
      callers in comm-central, but it seems they can switch to DOMWindowUtils
      trivially, as the DOMWindowUtils APIs also use the system principal and
      thus they can load any URL.
      
      I'll make sure to give them some time with the migration and/or help
      out of course.
      
      Differential Revision: https://phabricator.services.mozilla.com/D71263
      31821e1f
  8. 20 Mar, 2020 1 commit
  9. 17 Mar, 2020 1 commit
  10. 16 Mar, 2020 2 commits
  11. 19 Mar, 2020 1 commit
  12. 05 Mar, 2020 1 commit
    • Masayuki Nakano's avatar
      Bug 1569512 - Make `PresShell` ignore synthesized `mousemove` events coming... · c90d6c80
      Masayuki Nakano authored
      Bug 1569512 - Make `PresShell` ignore synthesized `mousemove` events coming from another process if the child process stores mouse location of synthesized mouse events for tests r=smaug
      
      The reason of intermittent failure of `test_bug656379-2.html` is, synthesized
      `mousemove` event coming from the parent process causes `mouseout` and
      `mouseleave` events of the last synthesized `mousemove` in the test.  The
      reason is, synthesized `mousemove` for tests makes `PresShell` in the content
      process record the cursor location, but won't make it `PresShell` in the
      parent process do it.  Therefore, parent process may synthesize `mousemove`
      event for the system cursor position which does not match with the synthesized
      mouse location in the content process.  Therefore, `:hover` state may be
      updated unexpectedly.
      
      This patch makes `WidgetEvent::mFlags` have a flag to indicate whether it
      came from another process.  Then, makes `PresShell::HandleEvent()` ignore
      synthesized `mousemove` events coming from another process only when the
      recorded mouse location was set by a mouse event synthesized for tests.
      
      Differential Revision: https://phabricator.services.mozilla.com/D65282
      
      --HG--
      extra : moz-landing-system : lando
      c90d6c80
  13. 27 Feb, 2020 1 commit
  14. 26 Feb, 2020 2 commits
  15. 13 Feb, 2020 1 commit
  16. 12 Feb, 2020 2 commits
  17. 23 Jan, 2020 1 commit
  18. 17 Jan, 2020 2 commits
    • Ting-Yu Lin's avatar
      Bug 1306634 Part 1 - Handle a long press to select a word in an unfocused... · 16737fbf
      Ting-Yu Lin authored
      Bug 1306634 Part 1 - Handle a long press to select a word in an unfocused iframe. r=mats,marionette-reviewers,whimboo
      
      Long-pressing on a text in an unfocused iframe to select a word never
      works. Currently, you need to single tap to focus the iframe first.
      
      Each PresShell has an associated AccessibleCaretEventHub. This patch
      fixes this bug by routing the event to the AccessibleCaretEventHub under
      the event point, and handle it there. If the event is not handled, then
      we handle it by the focused AccessibleCaretEventHub as before.
      
      I've experimented with only routing the event to the
      AccessibleCaretEventHub under the event point, without routing to the
      fallback focused AccessibleCaretEventHub. However, caret dragging didn't
      work in iframes. I didn't debug further.
      
      Differential Revision: https://phabricator.services.mozilla.com/D52767
      
      --HG--
      extra : moz-landing-system : lando
      16737fbf
    • Masayuki Nakano's avatar
      Bug 1543315 - part 21: Mark `PresShell::DidCauseReflow()` as `MOZ_CAN_RUN_SCRIPT` r=smaug · 487e463b
      Masayuki Nakano authored
      It removes a script blocker.  Therefore, although it depends on the caller
      whether it causes running script or not.  However, we should mark it as
      `MOZ_CAN_RUN_SCRIPT` for safer code.
      
      It's called only by the destructor of `nsAutoCauseReflowNotifier`.  Therefore,
      this patch also marks its constructor as `MOZ_CAN_RUN_SCRIPT` for making
      each creator method marked as `MOZ_CAN_RUN_SCRIPT` or
      `MOZ_CAN_RUN_SCRIPT_BOUNDARY`.
      
      Most of the creators is mutation listener methods.  However, `PresShell`
      does nothing after destroying `nsAutoCauseReflowNotifier`.  Therefore,
      this patch does not change the callers in MutationObserver.cpp to use
      `RefPtr<PresShell>` at calling them because changing it may cause performance
      regression.
      
      Perhaps, we should create another methods of `WillCauseReflow()` and
      `DidCauseReflow()` to avoid unnecessary `MOZ_CAN_RUN_SCRIPT` marking.
      However, I'm not sure whether most callers may run script or not because
      of outside of my knowledge.
      
      Differential Revision: https://phabricator.services.mozilla.com/D55805
      
      --HG--
      extra : moz-landing-system : lando
      487e463b
  19. 16 Jan, 2020 2 commits
    • Noemi Erli's avatar
      Backed out 2 changesets (bug 1306634) for causing assertion failures in... · 13b7594c
      Noemi Erli authored
      Backed out 2 changesets (bug 1306634) for causing assertion failures in nsAutoLayoutPhase.cpp CLOSED TREE
      
      Backed out changeset fb20602d0c39 (bug 1306634)
      Backed out changeset 35651fd9e240 (bug 1306634)
      13b7594c
    • Ting-Yu Lin's avatar
      Bug 1306634 Part 1 - Handle a long press to select a word in an unfocused... · 2e68f878
      Ting-Yu Lin authored
      Bug 1306634 Part 1 - Handle a long press to select a word in an unfocused iframe. r=mats,marionette-reviewers,whimboo
      
      Long-pressing on a text in an unfocused iframe to select a word never
      works. Currently, you need to single tap to focus the iframe first.
      
      Each PresShell has an associated AccessibleCaretEventHub. This patch
      fixes this bug by routing the event to the AccessibleCaretEventHub under
      the event point, and handle it there. If the event is not handled, then
      we handle it by the focused AccessibleCaretEventHub as before.
      
      I've experimented with only routing the event to the
      AccessibleCaretEventHub under the event point, without routing to the
      fallback focused AccessibleCaretEventHub. However, caret dragging didn't
      work in iframes. I didn't debug further.
      
      Differential Revision: https://phabricator.services.mozilla.com/D52767
      
      --HG--
      extra : moz-landing-system : lando
      2e68f878
  20. 09 Jan, 2020 1 commit
  21. 19 Dec, 2019 1 commit
  22. 18 Dec, 2019 3 commits
  23. 11 Dec, 2019 3 commits
    • Masayuki Nakano's avatar
      Bug 1543315 - part 20: Mark `PresShell::ContentStateChanged()` as... · 271d1b6d
      Masayuki Nakano authored
      Bug 1543315 - part 20: Mark `PresShell::ContentStateChanged()` as `MOZ_CAN_RUN_SCRIPT_BOUNDARY` r=smaug
      
      While it calls `RestyleManager::ContentStateChanged()`, it blocks script
      with `nsAutoCauseReflowNotifier`.  Therefore, it should be marked as
      `MOZ_CAN_RUN_SCRIPT_BOUNDARY` at least (looks like the other override,
      `DocAccessible::ContentStateChanged()` does not run script).
      
      There is a concern about the lifetime of `RestyleManager`.  It's destroyed
      when `nsPresContext::DetachPresShell()` is called.  It's called by
      `PresShell::Destroy()` and destructor of `nsPresContext`.  The latter is
      safe since `PresShell` owns `mPresContext` and it's never cleared.  However,
      I'm not sure about the former.  It might be better to create blocker of
      synchronous handling of `PresShell::Destroy()`.
      
      And also this does not make `Document::ContentStateChanged()` use
      `RefPtr<PresShell>` at calling it because it might cause performance
      regression, but it does not do anything after destroying
      `nsAutoCauseReflowNotifier`.
      
      Finally, for guaranteeing that the lifetime of `PresShell::mPresContext` is
      longer than `PresShell`, this makes it to `RefPtr<nsPresContext> const`.
      However, initializing it in constructor breaks other objects' initialization
      process since they assume that `PresShell::GetPresContext()` won't return
      valid pointer until the `nsPresContext` is attached.  For solving this issue
      safe, this patch keeps setting `mPresContext` in `Init()` with `const_cast`
      hack.
      
      Differential Revision: https://phabricator.services.mozilla.com/D55804
      
      --HG--
      extra : moz-landing-system : lando
      271d1b6d
    • Masayuki Nakano's avatar
      Bug 1543315 - part 19: Mark `PresShell::ReconstructFrames()` as `MOZ_CAN_RUN_SCRIPT` r=smaug · d586d5dc
      Masayuki Nakano authored
      It calls `Document::FlushPendingNotification()` so that we should mark it
      as `MOZ_CAN_RUN_SCRIPT`.
      
      And the method calls it of `mDocument` and `mDocument` is never modified
      after it's initialized.  Therefore, we can move the initializer to the
      constructor and make `RefPtr<Document>` to `RefPtr<Document> const`.  Thus,
      we can avoid unnecessary auto `RefPtr`.
      
      Differential Revision: https://phabricator.services.mozilla.com/D55803
      
      --HG--
      extra : moz-landing-system : lando
      d586d5dc
    • Masayuki Nakano's avatar
      Bug 1543315 - part 18: Mark `PresShell::FireResizeEvent()` as `MOZ_CAN_RUN_SCRIPT` r=smaug · 33564215
      Masayuki Nakano authored
      It dispatches a DOM event so that it should be marked as `MOZ_CAN_RUN_SCRIPT`.
      
      Differential Revision: https://phabricator.services.mozilla.com/D55801
      
      --HG--
      extra : moz-landing-system : lando
      33564215
  24. 06 Dec, 2019 1 commit
    • Gabriele Svelto's avatar
      Bug 1600545 - Remove useless inclusions of header files generated from IDL... · 69790bc6
      Gabriele Svelto authored
      Bug 1600545 -  Remove useless inclusions of header files generated from IDL files in accessible/, browser/, caps/, chrome/, devtools/, docshell/, editor/, extensions/, gfx/, hal/, image/, intl/, ipc/, js/, layout/, and media/ r=Ehsan
      
      The inclusions were removed with the following very crude script and the
      resulting breakage was fixed up by hand. The manual fixups did either
      revert the changes done by the script, replace a generic header with a more
      specific one or replace a header with a forward declaration.
      
      find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
          interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
          if [ -n "$interfaces" ]; then
              if [[ "$interfaces" == *$'\n'* ]]; then
                regexp="\("
                for i in $interfaces; do regexp="$regexp$i\|"; done
                regexp="${regexp%%\\\|}\)"
              else
                regexp="$interfaces"
              fi
              interface=$(basename "$path")
              rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
                  hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
                  if [ $hits -eq 0 ]; then
                      echo "Removing ${interface} from ${path2}"
                      grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
                      mv -f "$path2".tmp "$path2"
                  fi
              done
          fi
      done
      
      Differential Revision: https://phabricator.services.mozilla.com/D55443
      
      --HG--
      extra : moz-landing-system : lando
      69790bc6
  25. 21 Nov, 2019 1 commit
    • Hiroyuki Ikezoe's avatar
      Bug 1586986 - Fire visual viewport resize events and flush position:fixed... · 7afdb848
      Hiroyuki Ikezoe authored
      Bug 1586986 - Fire visual viewport resize events and flush position:fixed elements' layout in the same way what Chrome does. r=botond
      
      On Chrome, visual viewport resize event is fired repeatedly during dynamic
      toolbar transitions and visual viewport height obtained by the VisualViewport
      API is also changed, but in terms of layout the height value is never used
      until the dynamic toolbar height reaches to zero or is changed from zero.
      The height used at the time is the height for vh units when the toolbar height
      reaches to zero and the ICB height when the toolbar height is changed from zero.
      To do so, we need to have another visual viewport size in parallel to the
      original one and use them depending on situations.
      
      Differential Revision: https://phabricator.services.mozilla.com/D52338
      
      --HG--
      extra : moz-landing-system : lando
      7afdb848
  26. 01 Nov, 2019 1 commit
  27. 06 Oct, 2019 1 commit
  28. 25 Sep, 2019 1 commit
    • Emilio Cobos Álvarez's avatar
      Bug 1583534 - Further simplify PresShell::ResizeReflow. r=botond · 848d89d6
      Emilio Cobos Álvarez authored
      In particular, not let ResizeReflow take the old and new size. Most of the
      callers pass dummy values anyway.
      
      Instead, use the old size of the layout viewport. This ensures we fire resize
      events only if the layout viewport actually changes.
      
      This is important because the first resize of the mobile viewport manager
      after a navigation has an "old size" of 0x0, even though the layout viewport
      is initialized on presshell initialization to the right size.
      
      Thus, we fire resize events unnecessarily in that case, which is the root cause
      for bug 1528052.
      
      To do this, we need to shuffle a bit of code in nsDocumentViewer that deals with
      delayed resizes, to set the visible area _and_ invalidate layout, rather than
      setting the visible area and _then_ relying on doing a resize reflow.
      
      Further cleanup is possible, though not required for my android resizing fix, so
      will do separately.
      
      Differential Revision: https://phabricator.services.mozilla.com/D46944
      
      --HG--
      extra : moz-landing-system : lando
      848d89d6