Previously if saving a draft took longer than 2 seconds there
could be conditions where drafts could be saved concurrently.
This meant the composer could race with itself and raise conflicts.
This is likely to happen on bad internet connections or where
latency is really high.
Additionally a throttle was added so drafts save unconditionally
every 15 seconds.
Save draft in the model now properly and consistently returns a
promise.
Unlike other browsers, Safari maintains focus on elements even when
they are hidden. And since the composer is fixed-positioned when hidden,
closing the composer on a topic with several replies causes Safari to
scroll the window up.
Deliberately blurring the focused element fixes the issue.
This adds three new checks to the smoke test: that assets and service-worker.js do not
clear invalid cookies, but normal application routes do.
This functions as a test that the nginx config correctly strips out Set-Cookie responses
from the service-worker.js file.
Co-authored-by: Mark VanLandingham <markvanlan@gmail.com>
Co-authored-by: Robin Ward <robin.ward@gmail.com>
Co-authored-by: Mark VanLandingham <markvanlan@gmail.com>
Use a helper method to simplify creating a new register. Previously this would require creating lots of different methods manually, and adding every register to the clear/reset functions
Previously the code was very race condition prone leading to
odd failures in production
It was re-written in raw SQL to avoid conditions where rows
conflict on inserts
There is no clean way in ActiveRecord to do:
Insert, on conflict do nothing and return existing id.
This also increases test coverage, we were previously not testing
the code responsible for crawling external sites directly
In my original PR (#9647) I attempted to solve the problem of
using fake timers in acceptance tests by using the new sinon
clock.tickAsync methods. This way of doing things seems to be flawed,
however, as we are getting random spec timeouts starting with the
bookmark acceptance test where this was introduced.
I think I was going about things the wrong way. This commit introduces
a new function with callback (acceptanceUseFakeClock) that sets up the
fake timers using sinon.useFakeTimers with the shouldAdvanceTime option
set to true. This advances time at a normal rate of 20ms per tick, which
means that we are not freezing any time and existing setTimeout funcs.
should proceed as normal. Along with this the callback passed will
run clock.reset() at the end to make sure all the timers are cleaned
up correctly.
There is an optional third parameter after the callback, which is the
timezone. If the user is logged in for the acceptance test then their
timezone is used, otherwise we default to America/Denver.
Usage is (inside an acceptance test):
```
test("Name of the test", async assert => {
// first parameter is time to start fake clock at
await acceptanceUseFakeClock("2020-05-04T13:00:00", async () => {
// test code goes here e.g. await visit("/url");
});
});
```
This commit prevents a 500 error from occurring if someone is trying to
setup their discourse instance as a sso provider and they don't pass in
a `return_sso_url` in their payload.
We were getting errors like this in Reviewables in some cases:
```
ActiveRecord::StatementInvalid (PG::AmbiguousColumn: ERROR: column reference "category_id" is ambiguous
LINE 4: ...TRUE) OR (reviewable_by_group_id IN (NULL))) AND (category_i...
```
The problem that was making everything go boom is that plugins can add their own custom filters for Reviewables. If one is doing an INNER JOIN on topics, which has its own category_id column, we would get the above AmbiguousColumn error. The solution here is to just make all references to the reviewable columns in the list_for and viewable_by code prefixed by the table name e.g. reviewables.category_id.
