| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
Closes #22911
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Before we weren’t caching current_project_ref because normally the reference to
the current project doesn’t include the path with namespace. But now we store
the current project in the projects reference cache to be used for the same
filter when accessing using path with namespace of for subsequent filters executed on the cache.
|
| |
|
|
| |
without references
|
| |
|
|
|
|
|
|
| |
The previous fix introduced another leak; as it made
Banzai::Filter::SanitizationFiler#customized? always return false, so we
were always appending two elements to
HTML::Pipeline::SanitizationFilter::WHITELIST[:elements]. This growth in
the elements array would slow the sanitization process over time.
|
| |
|
|
| |
This reverts commit 504a3b5e6f0b2e2957cf1e4d9d8eebbf32234bdb.
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Use JavaScript tooltips for mentions
## What does this MR do?
- use JavaScript tooltips instead of plain title for mentions (issue, merge request, snippet, user, group, commit, commit range, milestone)
## Why was this MR needed?
JavaScript tooltips look nicer and can wrap.
## What are the relevant issue numbers?
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5261#note_13106713, fixes #21500
See merge request !5301
|
| | | |
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In Banzai::Filter::SanitizationFilter#customize_whitelist, we append
three lambdas that has reference to the SanitizationFilter instance,
which in turn (potentially) has a reference to the following chain:
context hash -> Project instance -> Repository instance -> lookup hash
-> various Rugged instances -> various mmap-ed git pack files.
All of the above is not garbage collected because the array we append
the lambdas to is the constant
HTML::Pipeline::SanitizationFilter::WHITELIST.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Do not look up commit again when it is passed to RelativeLinkFilter
## What does this MR do?
Use `context[:commit]` in RelativeLinkFilter instead of looking up commit using `context[:ref]`.
## Why was this MR needed?
Even though the commit object was already passed, unnecessary I/O is done to retrieve the commit object.
## What are the relevant issue numbers?
Fixes #20026
See merge request !5455
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Improve performance of SyntaxHighlightFilter
## What does this MR do?
This MR improves the performance of `Banzai::Filter::SyntaxHighlightFilter`. See e9bacc6575d0002c6cab620075dea3dc7f93f100 for more information.
## Are there points in the code the reviewer needs to double check?
Styling mostly.
## Why was this MR needed?
Syntax highlighting is rather slow.
## What are the relevant issue numbers?
#18592
## Does this MR meet the acceptance criteria?
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [x] ~~[Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)~~
- [x] ~~API support added~~
- Tests
- [x] ~~Added for this feature/bug~~
- [ ] All builds are passing
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
See merge request !5643
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
By using Rouge::Lexer.find instead of find_fancy() and memoizing the
HTML formatter we can speed up the highlighting process by between 1.7
and 1.8 times (at least when measured using synthetic benchmarks). To
measure this I used the following benchmark:
require 'benchmark/ips'
input = ''
Dir['./app/controllers/**/*.rb'].each do |controller|
input << <<-EOF
<pre><code class="ruby">#{File.read(controller).strip}</code></pre>
EOF
end
document = Nokogiri::HTML.fragment(input)
filter = Banzai::Filter::SyntaxHighlightFilter.new(document)
puts "Input size: #{(input.bytesize.to_f / 1024).round(2)} KB"
Benchmark.ips do |bench|
bench.report 'call' do
filter.call
end
end
This benchmark produces 250 KB of input. Before these changes the timing
output would be as follows:
Calculating -------------------------------------
call 1.000 i/100ms
-------------------------------------------------
call 22.439 (±35.7%) i/s - 93.000
After these changes the output instead is as follows:
Calculating -------------------------------------
call 1.000 i/100ms
-------------------------------------------------
call 41.283 (±38.8%) i/s - 148.000
Note that due to the fairly high standard deviation and this being a
synthetic benchmark it's entirely possible the real-world improvements
are smaller.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By using clever XPath queries we can quite significantly improve the
performance of this method. The actual improvement depends a bit on the
amount of links used but in my tests the new implementation is usually
around 8 times faster than the old one. This was measured using the
following benchmark:
require 'benchmark/ips'
text = '<p>' + Note.select("string_agg(note, '') AS note").limit(50).take[:note] + '</p>'
document = Nokogiri::HTML.fragment(text)
filter = Banzai::Filter::AutolinkFilter.new(document, autolink: true)
puts "Input size: #{(text.bytesize.to_f / 1024 / 1024).round(2)} MB"
filter.rinku_parse
Benchmark.ips(time: 15) do |bench|
bench.report 'text_parse' do
filter.text_parse
end
bench.report 'text_parse_fast' do
filter.text_parse_fast
end
bench.compare!
end
Here the "text_parse_fast" method is the new implementation and
"text_parse" the old one. The input size was around 180 MB. Running this
benchmark outputs the following:
Input size: 181.16 MB
Calculating -------------------------------------
text_parse 1.000 i/100ms
text_parse_fast 9.000 i/100ms
-------------------------------------------------
text_parse 13.021 (±15.4%) i/s - 188.000
text_parse_fast 112.741 (± 3.5%) i/s - 1.692k
Comparison:
text_parse_fast: 112.7 i/s
text_parse: 13.0 i/s - 8.66x slower
Again the production timings may (and most likely will) vary depending
on the input being processed.
|
| |
|
|
| |
(!5586)
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Optimize checking if a user can read multiple issues
## What does this MR do?
This optimizes various parts of the code so it can more efficiently check if a user can read a list of issues.
## Are there points in the code the reviewer needs to double check?
Yes, in particular `Ability.issues_readable_by_user` should be checked to make sure it correctly allows/restricts access to issues.
## Why was this MR needed?
Currently the general approach to checking if one can read an issue is to iterate over the issues to check and call `can?(user, :read_issue, issue)` for every issue. This is not efficient as the same work has to be done for every issue.
## What are the relevant issue numbers?
* #15607
* #17463
See merge request !5370
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The method Ability.issues_readable_by_user takes a list of users and an
optional user and returns an Array of issues readable by said user. This
method in turn is used by
Banzai::ReferenceParser::IssueParser#nodes_visible_to_user so this
method no longer needs to get all the available abilities just to check
if a user has the "read_issue" ability.
To test this I benchmarked an issue with 222 comments on my development
environment. Using these changes the time spent in nodes_visible_to_user
was reduced from around 120 ms to around 40 ms.
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Enable Rubocop cops that check access modifiers
## What does this MR do?
This MR enables Rubocop cops that detect methods that should be restricted but are the part of public API because of access modifiers used improperly.
This also fixes existing offenses.
## Why was this MR needed?
Some method in our codebase are public instead of being private because it is sometimes difficult to get it right without static analysis.
## What are the relevant issue numbers?
See #17478
Closes #17372
See merge request !5014
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | |
| |
| |
| | |
See #19985
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add support for inline videos in issue, MR and notes (on issue, commit, MR, and MR diff)
## What does this MR do?
It adds support for inline videos in issue, MR and notes (on issue, commit, MR, and MR diff). Most of the work was done by @hayesr in !3508 but a few improvements were still missing.
## Why was this MR needed?
To be able to play uploaded videos in GitLab!
## What are the relevant issue numbers?
Closes #4142.
## Screenshots
### Video players
-----
-----
## Does this MR meet the acceptance criteria?
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [x] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- Tests
- [x] Test `VideoLinkFilter`
- [x] Test in `spec/features/markdown_spec.rb`
- [x] Improve `spec/uploaders/file_uploader_spec.rb`
- [x] All builds are passing
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
See merge request !5215
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Handle videos in:
- MD preview in notes: commit, issue/MR, MR diff
- New notes in: commit, issue/MR, MR diff
- Persisted notes in: commit, issue/MR, MR diff
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Also, always add a link to download videos since video playback is
tricky. Also, it solves the issue with email client not supporting
videos.
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | | |
| | |
| | |
| | | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | |/
| |
| |
| |
| | |
* Registered video MIME types
* Currently supporting browser-supported formats with extensions that match the mime type
|
| |/
|
|
|
|
| |
Avoid multi-line ?: (the ternary operator). Use if/unless instead.
See #17478
|
| |
|
|
| |
original html string.
|
| |\
| |
| |
| |
| |
| |
| | |
Don't fail to highlight when Rouge doesn't have a lexer
Fixes issue introduced by upgrade to Rouge 2.0 (https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4691)
See merge request !5291
|
| | | |
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Display tooltip for mentioned users and groups
## What does this MR do?
Display tooltip for mentioned users and groups in Markdown.
## Are there points in the code the reviewer needs to double check?
I don't know.
## Why was this MR needed?
No tooltips were displayed.
## What are the relevant issue numbers?
fixes #17060
## Screenshots
See merge request !5261
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
| |
Rails.cache.read_multi
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
have been fully redacted and contain cross-project references.
The previous implementation relied on Note#cross_reference_not_visible_for?,
which essentially tries to render all the Markdown references in a system note
and only displays the note if the user can see the referring project. But this
duplicated the work that Banzai::NotesRenderer was doing already. Instead, for
each note we render, we memoize the number of visible user references and
use it later if it is available.
Improves #19273
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add blockquote fence syntax to Markdown
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/16564
Before Markdown rendering happens, this will transform this:
```
Let me quote this here email:
>>>
Dear friend,
How are you?
Greetings,
Me
>>>
```
Into this, saving me from having to prefix all of those lines with `>` manually when I copy some multiline text from another medium:
```
Let me quote this here email:
> Dear friend,
>
> How are you?
>
> Greetings,
>
> Me
```
See merge request !3954
|
