1. 29 Apr, 2021 2 commits
  2. 26 Apr, 2021 1 commit
    • Jeffrey I. Schiller's avatar
      Properly handle error while saving files · 0670fc6b
      Jeffrey I. Schiller authored
      When an error occurs while saving a file we need to put the associated
      file editor back in the dirty editors list. Otherwise data may be
      lost. Prior to this fix once i/o failed, the editor was considered clean
      and i/o would not be retried unless the editor was modified again. So
      for example if a designer attribute was changed, but the i/o failed, it
      would not get saved again, even if a change was made in the blocks
      editor and even if the “Save project” menu was used.
      
      Note: We do not re-schedule the failed i/o but instead depend on another
      user change (anywhere) or explicit use of the “Save project” menu. I
      considered re-scheduling the i/o but am concerned that if i/o is failing
      due to a server problem, a lot of clients retrying i/o may make it worse
      via the “thundering herd!”
      
      Change-Id: Ife50c3c20d407b4e009c639bc36c2596331342d7
      0670fc6b
  3. 16 Apr, 2021 3 commits
  4. 15 Apr, 2021 1 commit
  5. 12 Apr, 2021 1 commit
    • Jeffrey I. Schiller's avatar
      Add hostname to buildserver/vars · e97f1470
      Jeffrey I. Schiller authored
      We run 9-15 buildservers simultaneously and have a status page that
      reports the /buildserver/vars foreach server. However it is hard to know
      which status is for which buildserver. So we add the buildserver
      hostname here.
      
      Change-Id: I46fc59626cccf668ab57a5f81581273f0358fd1e
      e97f1470
  6. 07 Apr, 2021 1 commit
  7. 22 Mar, 2021 1 commit
  8. 17 Mar, 2021 1 commit
  9. 16 Mar, 2021 3 commits
  10. 07 Mar, 2021 1 commit
    • Jeffrey I. Schiller's avatar
      Mitigate Chrome 89 change · b4557d64
      Jeffrey I. Schiller authored
      Chrome 89 implements RFC8285 by default. It implements a general
      mechanism for RTP header extensions. We do not use these....
      
      Unfortunately the WebRTC library we are using in the Companion does not
      understand the extension request in the WebRTC offer message and refuses
      the offer completely, resulting in WebRTC not working from Chrome
      89 (and presumably onward).
      
      This change removes the extension from the offer prior to sending it to
      the Companion, so WebRTC works again.
      
      We believe this is harmless, because we do not use audio or video over
      WebRTC and this extension has no impact on the data channel (which we do
      use).
      
      Change-Id: I68f4ebaa2099ca0b4bbc7b1abd0a565dbde1f4e6
      b4557d64
  11. 01 Mar, 2021 2 commits
  12. 27 Feb, 2021 1 commit
  13. 22 Feb, 2021 1 commit
  14. 01 Feb, 2021 3 commits
  15. 27 Jan, 2021 1 commit
  16. 26 Jan, 2021 1 commit
  17. 20 Jan, 2021 7 commits
  18. 13 Jan, 2021 1 commit
  19. 12 Jan, 2021 1 commit
  20. 05 Jan, 2021 1 commit
  21. 16 Dec, 2020 1 commit
  22. 04 Dec, 2020 1 commit
  23. 01 Dec, 2020 4 commits