When installing an incompatible add-on, the add-ons manager checks first if a newer and compatible version of that add-on is available by sending a request either to the AUS or the provided update URL in the manifest.
If there's no update URL in the manifest and if the application does not provide an add-on update URL via preferences, the add-ons manager will error out and fail to notify that the said add-on is incompatible.
This commit addresses that by:
(a) preventing substitutions on the update manifest URL - this throws an error if it's empty; and
(b) failing early in the add-on update checker if the update manifest URL is empty and sends out an error notification
As part of telemetry removal, d60103257eb83db103f9acab54b1755486b7e9c1 removed the `reportResult` function which also handles the stopping of the sanity test. This also removes unused histogram enumeration values and revises/adds some comments.
Even if `<datalist>` is dynamically changed, the autocomplete controller still
uses the previous search result. If changed, we have to ignore the previous
result that may now be invalid.
Also, even if `<datalist>` is changed, we have to keep the selected index
(See Mozilla Bug 595069), so we cannot use `ResetInternalState` in this
situation because it resets the selected index.
This resolves#1509.
Since there really is no need to add file detection logic to the updater
if updating through AUS is old->new only anyway, replacing bzip2
handling with xz handling is fine, instead of adding it.
Considering the far superior compression of LZMA and MAR not being
a common archive format anyway, let's just K.I.S.S. it :)
A very very old bug and annoyance: tooltips with very long content without
spaces (e.g. long URLs or gibberish data) would just cut off and leave an
un-styled right border going over the widget's constrained space.
Because of an additional bug (still unsolved), this was never properly
addressed because solutions attempted didn't work.
The workaround for the secondary bug allows for word-break to now work and this
primary problem to be resolved.
Part of the UX refresh Pale Moon effort. This uses the new -moz-dark-theme media
query to make the logopage dark if the UI is dark, without explicitly relying on
(often not sane) system color values.
In almost all cases this is pointless to include, a ton of useless entries,
and there's no reason to have people post a full enumeration of installed
printers on their system when asked for TS information.
If there's a printer specific issue, people can always be asked to post relevant
info manually.
Mostly making parts conditional and removing blocks that are no longer
applicable, and a few minor edits otherwise to update links and text.
Resolves#1722
This would interfere with implementing thin scrollbars.
Almost all widgets provide a non-overridable size for scrollbar buttons, so it
makes no sense to specify min size for them. It is probably(?) a layout bug that
min size properties can override the value returned by GetMinimumWidgetSize
even if aIsOverridable is set to false, but removing this rule is simpler than
locating and fixing the issue in layout code ;)
This changes the toolkit theme for Linux and Windows (Mac already did this) to
style the input textbox on the findbar with -moz-appearance:none so as to give
us styling control (as opposed to using a native widget style) and apply a
neutral style to it.
Also ensures Mac remains readable in case of poorly contrasting text.
