## Summary
- Replace vendored `jquery-2.2.2.js` with `jquery-3.7.1.js` in
`gui/default/vendor/jquery/`
- Update script reference in `gui/default/index.html` to point to the
new file
- Update CDN reference in `cmd/infra/strelaypoolsrv/gui/index.html` from
`jquery-2.1.4.min.js` to `jquery-3.7.1.min.js`
## Why
The previously used jQuery versions (2.2.2 and 2.1.4) are vulnerable to
three known CVEs:
| CVE | Description | Fixed in |
|-----|-------------|----------|
| CVE-2015-9251 | XSS via cross-domain Ajax requests with non-text
content types | jQuery 3.0.0 |
| CVE-2020-11022 | XSS when passing HTML containing `<option>` elements
to manipulation methods | jQuery 3.5.0 |
| CVE-2020-11023 | XSS via passing HTML from untrusted sources to
manipulation methods | jQuery 3.5.0 |
jQuery 3.7.1 is the latest stable release and resolves all three.
## Compatibility notes
The GUI code was audited for jQuery 2→3 breaking changes. No removed
APIs are used:
- `.success()` / `.error()` calls throughout the codebase are
**AngularJS `$http`** promise methods, not jQuery — unaffected
- `.bind('beforeunload', ...)` is deprecated in jQuery 3 but not removed
— still works
- No usage of `.size()`, `.load()` event shorthand, `jQuery.isFunction`,
or `$.type()`
---------
Signed-off-by: Umer Azaz <umer_azaz@yahoo.com>
Co-authored-by: Jakob Borg <jakob@kastelo.net>
This adds a new folder-level configuration `FullBlockIndex`. It controls
whether we maintain the block index for a given folder -- currently
that's always true, now it becomes possible to turn off. The block index
is used for lookup of blocks across files and folders. Effectively, when
syncing a change, for each block, we check:
1. Is the block already present in the old version of the file? If so,
we can reuse (copy) it without network transfer. **This check is always
possible.**
2. Is the block already present in any other file in this folder or
other folders? If so we can copy it. **This check is only possible with
the full block index.**
3. We must transfer the block over the network.
Maintaining the full block index is costly in time, I/O and database
size. With this PR, maintaining the full block index becomes the default
for send-receive and receive-only folders only, with it disabled for
send-only and receive-encrypted folders. The block index is never useful
for encrypted folders, as blocks are encrypted separate for each file.
It is also not useful for send-only folders by themselves, though the
data in the send-only folder could be reused by other receive-type
folders if it were enabled.
For very large folders it may make sense to disable the full block index
regardless of folder type and just accept the resulting decrease in data
reuse.
Disabling or enabling the option in the GUI causes the index to be
destroyed or rebuilt accordingly.
https://github.com/syncthing/docs/pull/1005
---------
Signed-off-by: Jakob Borg <jakob@kastelo.net>
### Purpose
Fixes issue #10634.
### Testing
Manually tested by reproducing the issue:
- Created a new folder with "Add ignore patterns" enabled
- Verified that after saving, only the "Ignore Patterns" tab remains
accessible
- Confirmed that other tabs are visually disabled and no longer
clickable
### Screenshots
No visible UI changes.
### Explanation of the Fix
**Cause**
The issue was caused by only visually disabling tabs in the UI by
setting
their `href` attribute to an empty string (`href=""`). This made the
tabs
appear disabled, but they were still clickable, leading to confusing
behavior
where users could interact with the tabs without any actual navigation.
**Fix**
- Introduced `isFolderTabDisabled` to centralize the logic for
determining
whether a tab should be disabled
- Added `onFolderTabClick` to prevent interaction with disabled tabs
- Updated the HTML to remove tab behavior (such as `data-toggle="tab"`
and
`href`) when a tab is disabled
### Documentation
No documentation changes required.
Signed-off-by: JRNitre <nichinichisou67@outlook.com>
Co-authored-by: Jakob Borg <jakob@kastelo.net>
## Summary
Fixes issue #10458: When removing a folder without a Folder Label, the
confirmation dialog now shows the folder ID instead of an empty string.
### Before
> Are you sure you want to remove folder **?**
### After
> Are you sure you want to remove folder **dnjdr-hssze**?
### Changes
Modified `gui/default/syncthing/folder/removeFolderDialogView.html`:
```html
<!-- Before -->
<p translate translate-value-label="{{currentFolder.label}}">
<!-- After -->
<p translate translate-value-label="{{currentFolder.label || currentFolder.id}}">
```
### Testing
1. Create a folder without a label
2. Open the folder edit dialog
3. Click remove
4. Verify the confirmation dialog shows the folder ID instead of blank
Fixes#10458
Signed-off-by: RealCharlesChia <161665317+RealCharlesChia@users.noreply.github.com>
### Purpose
There were some additional regression created during #10563 and #10631 which are:
* Folders were not being ordered by their label within their group
* Local device could still show up randomly with the list of remote devices
The respective fixes in this PR does the following:
* Ensure sorting of the grouped folders (and devices) are done by group name (the top level map key) and then by the specified nested object property or a fallback property if specified property value is empty. So in the case of the folders it's `label` and device is `name`.
* When populating the `devicesGrouped` using `$scope.otherDevices`, do this within a watcher on `$scope.myID` as this is what `$scope.otherDevices` relies on to determine what is a remote device. This is required because `$scope.myID` might not be populated yet given the indeterministic call order being made to `refreshSystem` and `refreshConfig`.
### Testing
Populate folders and devices into different groups, and ensure the ordering is correct and the local device is not showing in remote devices even after many, many refreshes on the UI or restarts of syncthing entirely.
### Screenshots
Before the fix
<img width="1108" height="951" alt="Screenshot_20260409_083910" src="https://github.com/user-attachments/assets/6eb8cacc-5924-4612-aa70-29ed4f691233" />
After the fix
<img width="1090" height="934" alt="Screenshot_20260409_084553" src="https://github.com/user-attachments/assets/f5b74391-228a-43d3-b5ee-433958236d84" />
### Documentation
N/A
## Authorship
Ben Norcombe [bennorcombe@pm.me](mailto:bennorcombe@pm.me)
The css and svg files have license headers, but there were no separate
license files like the other vendored assets in `gui/default/vendor/*`.
This issue came up while we were working on updating and modernizing the
syncthing package in Fedora Linux.
This commit copies the existing license headers into separate files
to make things easier for license scanning and SCA tools,
such as [Go Vendor Tools](https://fedora.gitlab.io/sigs/go/go-vendor-tools/).
* [...]/css/LICENSE.txt is copied from the license header in
gui/default/vendor/fork-awesome/css/fork-awesome.css.
* [...]/fonts/LICENSE.txt is copied from the license text in the
<metadata> tag of
gui/default/vendor/fork-awesome/fonts/forkawesome-webfont.svg.
Relates: https://src.fedoraproject.org/rpms/syncthing/pull-request/4
Signed-off-by: Maxwell G <maxwell@gtmx.me>
Based on user requests from Weblate:
* `@miryusifrahimov` for Azerbaijani
* `@halbast` für Kurdish (Central)
Both seem to be legit and have previously contributed translations on
Weblate.
Signed-off-by: André Colomb <src@andre.colomb.de>
IMHO the logic here was inverted. The only use for the report data is to
show a preview when we ask the user whether they want to participate in
usage reporting. However, the GUI would first load the report data and
then consider whether we wanted to show that dialog or not. Instead,
only load if it we're going to show the dialog.
Signed-off-by: Jakob Borg <jakob@kastelo.net>
Currently, the input field has no step defined, meaning that it can be
increased with the arrow keys by the default value of "1". Considering
the fact that the default value is "3600" (seconds or one hour), it is
unlikely that the user wants to change it with such minimal steps.
For this reason, change the default step to "3600" (one hour). If the
user needs more granual control, they can still input the value
in seconds manually.
Signed-off-by: Tomasz Wilczyński <twilczynski@naver.com>
Signed-off-by: Tomasz Wilczyński <twilczynski@naver.com>
Currently, the bandwidth limit input fields have no step defined, and as
such they use the default value of "1". Taking into account the fact
that these fields use KiB as their measurements, it makes more sense to
use larger steps, such as "1024" (1 MiB), as in most cases, it is very
unlikely that the user needs to have byte-level control over the limits.
Note that these steps only apply to increasing the values by using the
arrow keys, and the user is still allowed to input any value they want
manually.
Signed-off-by: Tomasz Wilczyński <twilczynski@naver.com>
Signed-off-by: Tomasz Wilczyński <twilczynski@naver.com>
