
This change reverts visible tabs to use the » character. A few different approaches have been used for rendering these tab indicators: I: Before the Annotation Pipeline, tab indicators were configured by a class that was optionally applied to tab elements by the diff builder. The class was guarded by the show_tabs preference and a CSS rule created a `::before` pseudo element to insert the character. (Thus also preventing the » from being copyable text.) II: When the Annotation Pipeline was implemented, the ordering of layers called for intraline difference elements being rendered *inside* tab indicators. As a result, the » indicator would sometimes have a different background than the intraline difference, looking sloppy. To solve this, the pseudo element was positioned using absolute, allowing the pseudo element to consume no horizontal space and and the intraline background to extend across the entire tab. III:When performance tuning, it was discovered that the absolute-positioned tab indicators were positioned incorrectly when GPU acceleration was hinted for the diff, so the containing tab elements were made relative. IV: Continuing performance tuning, the tab indicators seemed to slow scrolling on very large diffs with tabs. It was mistakenly assumed (by me) that this was related to the pseudo-elements when it was actually caused by the thousands of positioning contexts they created using relative and absolute. Instead they were modified to use strike-through instead of a pseudo element, which was more-performant, but less-usable (it looked bad). With this change, we roll-back the clock a little and solve a core problem: namely that tab indicators were not annotated inside the intraline differences. Fixing that, positioning tricks are no-longer needed to make the background look right. To do this, we decouple the tab elements (which control tab width) from the tab indicators (which optionally make tabs visible). This is done using an annotation layer that inserts tab indicator elements wherever a tab character is used in the source content, and it does so after intraline differences have been applied. Bug: Issue 4441 Change-Id: I4fea2a3a20a7039bfeb746bd1e1c1004e43c4801
PolyGerrit
Installing Node.js
# Debian/Ubuntu
sudo apt-get install nodejs-legacy
# OS X with Homebrew
brew install node
All other platforms: download from nodejs.org.
Optional: installing go
This is only required for running the run-server.sh
script for testing. See below.
# Debian/Ubuntu
sudo apt-get install golang
# OS X with Homebrew
brew install go
All other platforms: download from golang.org
Add [go] to your path
PATH=$PATH:/usr/local/go/bin
Local UI, Production Data
To test the local UI against gerrit-review.googlesource.com:
./polygerrit-ui/run-server.sh
Then visit http://localhost:8081
Local UI, Test Data
One-time setup:
- Install Buck for building Gerrit.
- Build Gerrit and set up a local test site. Docs here and here.
When your project is set up and works using the classic UI, run a test server that serves PolyGerrit:
buck build polygerrit && \
java -jar buck-out/gen/polygerrit/polygerrit.war daemon --polygerrit-dev \
-d ../gerrit_testsite --console-log --show-stack-trace
Running Tests
One-time setup:
# Debian/Ubuntu
sudo apt-get install npm
# OS X with Homebrew
brew install npm
# All platforms (including those above)
sudo npm install -g web-component-tester
Run all web tests:
buck test --no-results-cache --include web
The --no-results-cache
flag prevents flaky test failures from being
cached.
If you need to pass additional arguments to wct
:
WCT_ARGS='-p --some-flag="foo bar"' buck test --no-results-cache --include web
For interactively working on a single test file, do the following:
./polygerrit-ui/run-server.sh
Then visit http://localhost:8081/elements/foo/bar_test.html
Style guide
We follow the Google JavaScript Style Guide with a few exceptions. When in doubt, remain consistent with the code around you.