Compilers would complain about using user-defined type as return type
of extern "C" functions. A struct is considered a user-defined type if
there is any non-trivial constructor.
Having a type without non-trivial constructor for borrowed type would
be very inconvenient. Actually the currently borrowed type doesn't seem
to provide any additional safety / benefit over a plain pointer.
MozReview-Commit-ID: ncxmCEWCkv
--HG--
extra : rebase_source : 43a95bbcb05759f27837629daec6ce915a68b062
extra : source : 2a544c24bfb6a3412e59acbee89a5a393c31d5b6
It will be called in the next flush, so no need to do it eagerly.
MozReview-Commit-ID: 1B8pzn0dqBO
--HG--
extra : rebase_source : 79a4203d13a2b9d48cd9c9d6fa5c5e08974d4765
extra : source : 162b17483adb18d3d05d866853fb8f841dee846d
This patch also makes sure that we correctly grab a weak reference to the
related window instead of just setting a "relatedBrowser" property directly on
the JS object (which shadows the XBL property getter).
MozReview-Commit-ID: 97VQyCoY1Cj
H264 decoders always use those anyway, so may as well use them in the demuxer if SPS NAL is available.
This guarantees that we have correct dimensions when reading the MP4 metadata, and will have the side benefit that when loadedmetadata is fired, the dimensions provided at the time will be final; not having to wait to decode the first frame.
MozReview-Commit-ID: 3j70Xqw8jJY
--HG--
extra : rebase_source : 6bc0f1fa1c2db35bcaa683cc1a68042d122e2892
Start offset of composition string is fixed when composition string becomes non-empty in focused editor. In other words, until composition string is fixed, composition start offset may be changed from selection start offset at dispatching compositionstart event. Especially, in e10s mode, pending keyboard events usually change composition start offset.
So, while there is composition, IMEHandler should use query events querying text rect or text content relative to actual start offset of composition string because native IME believes composition string at selection selection start when starting composition in the main process.
MozReview-Commit-ID: 3hinwozl9Ow
--HG--
extra : rebase_source : 4b79dd4f53aa51edfc78ff08c07a710160a8de01
The presence of these globals interfere with the attempt to get ext-*.js
scripts to load in a content process because these globals are only
available in the main process.
MozReview-Commit-ID: 7syjAGcuUnu
--HG--
extra : rebase_source : d614424d50bbb2a5dea6c23e4dae1586b9efe4fb
The main motive for this patch is to remove the use of the GlobalManager
global (which was used to see if an extension ID is valid, which was
specifically added in order to create thebrowser_ext_lastError.js test).
To preserve test coverage I implemented a full validation of the
runtime.sendMessage method.
Now the error for a non-existent extension is identical in both the
content script and background pages. Note that this also fixes a
minor privacy leak: Previously extensions could see whether another
extension is installed by sending a message to the specified extension
and using the different responses to see whether another extension is
installed.
MozReview-Commit-ID: 82R97Ei25Xr
--HG--
extra : rebase_source : 900a65e695afd6db83d5102f515dc29d46d001f1
This adds a new highlighter in devtools/server/actors/highlighters.
For now this highlighter isn't used and can only display grid lines
as provided by node.getGridFragments().
