| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We now take the DPI value into account when calculating the width and
height of the browser window. Furthermore, using GetAvailRect() helps
to take care of taskbars that could influence the available height.
At least two corner-corner cases remain:
1) On some Linux machines the height of the titlebar is not included in
outerHeight(). Thus, we guess with a pretty safe margin.
2) On some systems retrieving the available height is giving the screen
height back which could lead to problems if taskbars are available.
Fixing those two problems (and presumably others yet to be reported) is
out of the scope for this patch.
However, in order to give the user the option to overwrite the
miscalculation two preferences
extensions.torbutton.window.innerWidth
extensions.torbutton.window.innerHeigth
are consulted. If they are set their values are used when resizing the
inner window.
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
| |
already exist
|
| | |
|
| |
|
|
|
|
| |
If the remote check does not complete successfully, look at the
status code associated with the underlying nsIRequest and fail the
tor check when the status is "proxy connection refused."
|
| |
|
|
|
|
|
|
|
| |
It turns out that clicking several times on New Identity very quickly
may lead to unexpected behavior, to errors like "TypeError:
b.webProgress is undefined" and a somewhat broken browser: clicking on
New Identity again after this error showed up shuts the browser down,
for example. Thanks to a patch by a cypherpunk we disable the New
Identity menuitem after the first click which resolves this issue.
|
| |
|
|
|
|
| |
Some users may not have access to their Tor control port, and would prefer a
remote Tor check instead, even if they are not using a transproxy. This pref
allows them to specify this.
|
| |
|
|
|
|
|
|
| |
If a user is clicking on the Accept button on the preferences dialog
more than once the code in torbutton_prefs_save() is executed more than
once as well which may lead to unexpected and unintended behavior. We
fix this thanks to a patch by a cypherpunk by disabling the Accept
button after the first click.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
(Or the search engine names, but we'll deal with that later).
I fixed this in transifex too, but don't want to wait for transifex to get
pulled again.
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/chrome/content/aboutTor/aboutTor.xhtml
src/chrome/locale/eu/aboutTor.dtd
src/chrome/locale/fa/aboutTor.dtd
src/chrome/locale/ja/aboutTor.dtd
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Our use of entities that contained trailing spaces was a bad idea: they
got lost during the translation process. Instead, we now use a template
that contains a snippet of HTML, with the search engine URLs as separate
property strings.
We did our best to preserve the existing translated strings, converting
them to the new scheme and adding the missing spaces.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
collisions.
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
The external application blocker code suppresses error messages that are
triggered by the JS -> C++ bridge. The downside is that content type
sniffing leads to browser freezes. This patch overrides Firefox methods
in order to gain the former while avoiding the latter.
|
| |/ / |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
Exceptions can apparently happen in rare, unknown cases while clearing
search/find boxes.
|
| | |
| |
| |
| |
| | |
We now position the arrow so it points to the toolbar button regardless
of its position.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In order to be sure that no other extension is resizing the inner window
due to merging its overlay into the chrome we resize the window (again)
via a mutation observer and a setTimeout(0) call. The mutation observer
helps us as DevTools code is modifying the DOM during start-up.
This approach minimizes the possible usability issues as well as the
window just gets larger by some pixels while being visible (if it gets
larger at all, i.e. if proper resizing did not succeed before the window
got visible). Provided it gets visible in the first place before the
final resizing gets applied.
|
| | |
| |
| |
| |
| | |
We should clear permissions on New Identity as e.g. the web notification
permission would be able to link the old and the new session otherwise.
|
| | |
| |
| |
| |
| |
| |
| | |
On some OS/desktop combinations there is a auto-maximize feature that
breaks our efforts to resize the inner window to a multiple of 200x100
on start-up. We fix that by listening to the sizemodechange event and
resizing the window again in case it got indeed maximized.
|
| | |
| |
| |
| |
| |
| | |
Without an update URL specified, Firefox will still ping addons.mozilla.org
for an update. If someone manages to register a fake Torbutton at our UID, it
could get pushed out to users.
|
| | |
| |
| |
| |
| |
| |
| | |
Also sync up the banned ports list with TBB.
These settings shouldn't get applied in TBB normally. This is just defensive,
in case someone somehow manages to toggle Tor state still.
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
| |
Use the NoScript service function directly.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Also bump version and changelog entry.
|
| | |
|
| |
|
|
|
| |
Needed on FF24. The current cache, cookie and DOM Storage APIs do not
otherwise clear private browsing mode data.
|
| | |
|
