Build slaves on automation are based on Centos 6, which doesn't have a
recent enough version of libstdc++ for our new requirements. But since
we're building with a recent GCC or clang with its own libstdc++, we do
have such a libstdc++ available somewhere, and the compiler picks it
when invoking the linker.
Problems start happening when we execute some of the built programs
during the build, like host tools (e.g. nsinstall), or target programs
(xpcshell, during packaging). In that case, we need the compiler's
libstdc++ to be used. Which required adding the GCC or clang library
directory to LD_LIBRARY_PATH.
Unconveniently enough, the clang 3.5 tooltool package we're using for
ASAN builds until we can update to at least 3.8 (bug 1278718) doesn't
contain libstdc++.so. So for those builds, pull the GCC package from
tooltool as well, and pick libstdc++ from there.
Similarly to the considerations about glibc, the Linux compatibility matrix
(https://developer.mozilla.org/en-US/Firefox/Linux_compatibility_matrix)
tells us no distro with Gtk+3 3.4 has a version of libstdc++ older than
4.6.
The data in the matrix doesn't go to that level of detail, but Ubuntu
12.04 LTS, being the only one with version 4.6 (others have at least
4.7), it's worth noting it has version 4.6.3. Which means we can safely
require libstdc++ symbols version 3.4.16 (which were added in 4.6.1).
This will allow us to remove a lot of the stdc++ compatibility hacks.
The requirement for glibc has been set to version 2.7 for a long while.
Spidermonkey uses the pthread_setname_np symbol, which is only available
since glibc 2.12. So far, we've been fortunate that the symbol doesn't
end up in libxul, or tests that link to js directly, because the symbol
is eliminated as being called by effectively dead code.
There are multiple reasons why this is going to change, one of which
being changes to the way things are linked, that will make the linker
not eliminate that code in some cases. Another is that eventually, the
separation of build systems between js and top-level is going to fade,
and the glibc checks, which apply to all gecko binaries, will also apply
to js binaries. They currently are not happening, and would fail because
of pthread_setname_np if they were.
Taking a step back, as of version 46, the mozilla.org builds require at
least Gtk+3 3.4. Which means the requirements for the underlying system
have received a dramatic bump, and it's time to revisit the requirements
for binary compatibility.
I went through all my notes from all the recent times binary compatibility
has been considered, and put together a compatibility matrix on MDN from
that data as well as more recent data that I could find here and there,
about the major non-rolling-release distros (RHEL, Fedora, SuSE, Debian,
Ubuntu)
https://developer.mozilla.org/en-US/Firefox/Linux_compatibility_matrix
Considering the data there, none of the distros that have at least Gtk+3
3.4 have a glibc older than 2.13. The list of symbols that 2.13 provides
that 2.12 doesn't have is not large enough, though, to really care about
depending on 2.13.
This patch defines two constants kSelectionTypeCount and kPresentSelectionTypeCount. The former is same as nsISelectionController::NUM_SELECTIONTYPES. The latter is kSelectionTypeCount - 1 for excluding SELECTION_NONE. The latter is useful in some loops which handle all selection types except SELECTION_NONE.
Note that this patch fixes a bug of nsFrameSelection. That doesn't treat SELECTION_NONE as a selection (see the definition of index), however, it defines redundant item and doesn't use it actually. Additionally, it computes invalid selection type in each loop. Therefore, without this patch, debug build hits MOZ_ASSERT() in ToSelectionType(RawSelectionType).
Note that these constants are defined as anonymous enum because we cannot define as const (or static) even with extern. If we'd try to do it, it caused link error or not available in nsFrameSelection.cpp as constant value since they were not initialized if they were initialized in nsSelection.cpp. Therefore, these constants are defined as enum items but using "k" prefix.
MozReview-Commit-ID: H6sH7NBEXlE
--HG--
extra : rebase_source : fd517d5fc2e2d5dc2f96313e2802fd1719817af7
This patch defines mozilla::SelectionType as an enum class. This is safer than nsISelectionController::SELECTION_* since setting illegal value to its variable is checked at build time. So, as far as possible, this should be used everywhere (but of course, this isn't available in scriptable interfaces).
And also this implements some useful methods for managing SelectionType and RawSelectionType which are implemented in layout/nsSelection.cpp because nsISelectionController is implemented by both PresShell and nsTextEditorState. Therefore, implementing one of them may make hard to find them. On the other hand, nsSelection.cpp is a better file name to look for them.
Note that this patch creates mozilla::Selection::RawType() for binding. Native code should keep using Selection::Type() but the binding code needs to use RawType() due to impossible to convert from SelectionType to RawSelectionType without explicit cast.
MozReview-Commit-ID: 81vX7A0hHQN
--HG--
extra : rebase_source : d9f88e217c713c60d1c2578ce6421c73ccba8650
A listener was added for stylesheet changes only if the stylesheet already
contributed to the page before the modification. So if there was a stylesheet
without any rule matching a node of the page, when a rule was created in it for
the current selected node in the markup view, the rule view wasn't refreshed.
The fix here is to emit an event, from the TabActor, when a StyleSheetActor is created,
and listen to such event to watch for changes in it, in order to update the rule view.
Modify an existing rule view/stylesheet editor sync test to make sure this bug is fixed.
MozReview-Commit-ID: H3szbUnchQP
--HG--
extra : transplant_source : %F7%E0%D2%8B%B3%D2%C3%1F%F8%88%03%AA%10Q%E4%B8h%0C%BE_
This patch converts the inspector's context menu implementation away from
directly using XUL menus, and updates a number of tests to match.
MozReview-Commit-ID: L8aL23BUmXS
mozilla::SelectionType will be an enum class. Therefore, we need to rename SelectionType with a word "raw" since it's a type for raw nsISelectionController::SELECTION_*.
MozReview-Commit-ID: K8SO0bbpv0Y
--HG--
extra : rebase_source : 56e3ac852657ef4795d718d2da09b16903c2e66c
