I would like to nsIAtom and mozilla::dom::Element version of CreateAnonymousElement to clean up code. When getting/setting attirubte, editor sometimes use string, not nsGkAtoms. We should use new mozilla::dom::Element methods.
Also, we should add _moz_anonclass to atom list that uses on editor.
MozReview-Commit-ID: ICaAWVPjcej
--HG--
extra : rebase_source : 9585214aa678c16905250265a75b817c90246fcc
We have no mochitest for objectResizing and inlineTableEditing. So I add simple test for this.
MozReview-Commit-ID: Hnjpopr3h5F
--HG--
extra : rebase_source : 8cb81a89f11d4092f2adaa8822733f861a71ace1
For now, let's make the scope of EditActionResult variable in them smaller without big change.
MozReview-Commit-ID: 9vDoU9bUdVO
--HG--
extra : rebase_source : 6cdd50954d6cfe1fa80aeee5b06b3fec6b1ada3d
In a lot of places, edit action handlers and their helper methods return nsresult and aHandled and aCanceled with out params. However, the out params cause the code complicated since:
* it's not unclear if the method will overwrite aHandled and aCanceled value.
* callers need to create temporary variable event if some of them are not necessary.
This patch rewrites the helper methods of HTMLEditRules::WillDeleteSelection() with it.
MozReview-Commit-ID: CJv75KdOdXf
--HG--
extra : rebase_source : 708d378bdd0ddc4ae984de9294525b01a829b0b7
When selection is collapsed and JoinBlocks() doesn't handle nor cancel the action, WillDeleteSelection() should move selection to the start/end of leftmost/rightmost editable leaf node and retry to handle the action again.
For avoiding infinite loop, it checks if selected node is changed actually before calling itself again.
MozReview-Commit-ID: GtEC4dim3r9
--HG--
extra : rebase_source : f84afd754e71f441c3fad15456d20a11c42dd6de
When HTMLEditRules::WillDeleteSelection() tries to remove something from the end/start of a block to its last/first text node but it's contained by block elements, it tries to join the container and the block. However, JoinBlocks() always fails to join them since it's impossible operation. In this case, HTMLEditRules::WillDeleteSelection() should retry to remove something in the leaf, however, it's impossible for now because JoinBlocks() and its helper methods don't return if it handles the action actually.
This patch renames |JoinBlocks()| to |TryToJoinBlocks()| for representing what it is. And this patch adds |bool* aHandled| to the helper methods. Then, *aHandled and *aCancel are now always returns the result of each method. Therefore, for merging the result of multiple helper methods, callers need to receive the result with temporary variables and merge them by themselves.
Note that when they modify DOM node actually or the action should do nothing (for example, selection is across tables), aHandled is set to true.
MozReview-Commit-ID: 7ApUOgtLUog
--HG--
extra : rebase_source : 4abc1ec208107b782a719df058623fd7f92d180c
If not text node, QI to nsIContent will be failed. So we should use IsNodeType (Or EditorBase::IsTextNode) without QI for detection of text node.
Also, to get content length into text node, we should use TextLength() simply instead of getting content string. It can reduce memory allocation.
MozReview-Commit-ID: C8EKxfUBjTP
--HG--
extra : rebase_source : 30614bd21393f96f9a9b13aeb5a742fa8c6eb83f
extra : amend_source : 8b956f9fbd521f7c9503bdb5481694579cb6e3e9
The test compaires 4 screenshots for checking spellchecker's behavior. However, the input element is sometimes not painted correctly on Linux.
Even if I make it wait more delay before taking screenshot, the random failure isn't fixed. So, I guess that it's a bug of gfx of Theme API of GTK.
On the other hand, the most important thing here is, compairing the foreground contents of the input element. Therefore, this patch makes the background and border of the input element transparent. That prevents to use Theme API. This must be enough for fixing the random orange.
MozReview-Commit-ID: L2uXcPLvbNg
--HG--
extra : rebase_source : 451f1c45d70ceb8406ea9749f0dfa3264c615151
Although GetGoodSelPointForNode only supports ePrevious or eNext as action, we use other action. So we should add aseetion for it.
MozReview-Commit-ID: 3gLFFTAdNxU
--HG--
extra : rebase_source : b22cd532b6072e19fe1bff7f90a0e4a4ae4236e1
extra : histedit_source : 117509f1b76a382e8b23c5fa3345b81460385e56
When using CompositionTransaction, text node will be inserted into IMETextNode, not aTextNode of parameter. So we should use it for listener.
MozReview-Commit-ID: 72a3ZjF1wsz
--HG--
extra : rebase_source : 325909c0d141c238ab41e33d7f3959f4db27339e
extra : histedit_source : 52d6fc9d2668e4e41783e524276d7041eec0301c
Although PlaceholderTransaction will use the selection on Merge, it is too late to use UpdateRange. Because RangeUpdater will be used after DoTransaction is finished. So we should update selection on DoTransaction.
Also, part 1 fix doesn't update selection correctly via RangeUpdater when IME composition is multiple node.
MozReview-Commit-ID: 9so9tR8uQ6t
--HG--
extra : rebase_source : 02a8bebe6c89ceb023bd598b77b40c5817cd4007
extra : histedit_source : d114420552779d3352637c5554bf9e90e6e9cd40
Since the selection into PlaceholderTransaction isn't updated via RangeUpdater, UndoTransaction may return error when selection/caret position is changed. Then, redo is failed.
So we should add selection into PlaceholderTrancation to RangeUpdater.
MozReview-Commit-ID: LcUIiUExNhx
--HG--
extra : rebase_source : 9e1a71a7f497181171209ac05edcbddae227ab93
extra : histedit_source : 200dfd7957bf1b4dc92af72bb8b864cb457d62ab
We need skip this test on Android. Although mochitest doesn't use native IME data, Android's GeckoEditable.java wants to access native IME composition. See bug 1315898.
MozReview-Commit-ID: BNCKmDEmwKw
--HG--
extra : rebase_source : e7be1cb9e5c7c0fb4283f81541fc7441f52a1101
Google Keep uses range.insertNode on input event. So, text node will be inserted into current caret position.
Microsoft IME's caret is after composition string, but ATOK's caret is before it. So when using ATOK, this issue occurs. By range.insertNode, text nodes that have IME attribute becomes multiple text nodes. But CompositionTransanction doesn't consider that IME range isn't single text node. Although it replaces current composition string with new string on first text node, it doesn't delete composition string on other text node.
MozReview-Commit-ID: 9uRx0A9mppx
--HG--
extra : rebase_source : fe0754cee2197822ca6ac9ebed13013a8f13b606
Currently, when selection is collapsed at an empty text node, the behavior of each major browser is different.
When you remove the last character of non-empty text node followed by empty text nodes, Chromium removes all following empty text nodes. However, Edge never removes empty text nodes even when selection is collapsed at an empty text node.
With this patch, our behavior becomes same as Edge. I think that we should take this for keeping backward compatibility since Gecko never removes empty text nodes. So, in other words, this patch makes Backspace key press at an empty text node modify the preceding non-empty text node.
When you remove the first character of non-empty text node preceded with empty text nodes, Edge removes all preceding empty text nodes. However, Chromium and Gecko keeps previous empty text nodes than caret position. So, we should keep current behavior for backward compatibility. In other words, this patch makes Delete key press at an empty text node modify the following non-empty text node and keep current behavior.
The fixing approach of this is, making WSRunObject::PriorVisibleNode() and WSRunObject::NextVisibleNode() ignore empty text node. This should make sense because empty text node is not a visible node. (On the other hand, when the DOMPoint has a null character, it should treat as visible character. That is visible with Unicode codepoint.)
MozReview-Commit-ID: 11YtqBktEvK
--HG--
extra : rebase_source : 70fa858866cc768179c1ca6a869e1a5c7cfe6e1a
Giving '0' (literal zero) to nsCOMPtr is now ambiguous, as both
nsCOMPtr(decltype(nullptr)) and nsCOMPtr(T*) could be used.
In any case, our coding standards mandate the use of 'nullptr' for pointers.
So I'm changing all zeroes into nullptr's where necessary.
MozReview-Commit-ID: LXiZTu87Ck6
--HG--
extra : rebase_source : f9dcc6b06e9ebf9c30a576f9319f76a51b6dc26f
Giving '0' (literal zero) to RefPtr is now ambiguous, as both
RefPtr(decltype(nullptr)) and RefPtr(T*) could be used.
In any case, our coding standards mandate the use of 'nullptr' for pointers.
So I'm changing all zeroes into nullptr's where necessary.
MozReview-Commit-ID: A458A4e9for
--HG--
extra : rebase_source : bc4107ce1767329e3dddfe34c55ba79202192e06
Even when editor receives eCompositionStart event, the active composition may have gone since web contents can listen to composition events before editor (so, web contents can commit the composition before "compositionstart" reaching focused editor).
Therefore, editor shouldn't crash as unexpected scenario. Instead, it should do nothing in such case.
Note that when editor receives 2nd or later "compositionupdate" or "text" event, it should not modify composition. However, currently, it does that. This patch does NOT fix it since it's really rare case. It should be fixed in another bug because this should be uplifted (crashing with some IMEs on Android is serious).
MozReview-Commit-ID: HIbMy4eFRMw
--HG--
extra : rebase_source : a98661ab2c1c8ee67ef551af3d1770b61cd25c84
The main targets of this refactor are:
1. Move most of the logic of distinguishing properties and custom
properties from nsDOMCSSDeclaration into css::Declaration, which
gives ServoDeclarationBlock more flexibility to implement.
2. Rename those methods of css::Declaration to provide a clear interface
which makes sense for implementing in ServoDeclarationBlock, and also
avoid method overload, which can impede the forward macro, on them.
MozReview-Commit-ID: 2cCqF855TVK
--HG--
extra : source : 3837e1e558caac4f2901e838371e97c17821530e
The change from ok() to is() in tests is so that the failure message is
more informative -- it now tells you the returned exception.
This commit omits test_contenteditable_text_input_handling.html because of test
failures that I haven't figured out.
MozReview-Commit-ID: 37cYlQlJZm7
I added an extra check to ensure that the test wasn't passing because
doCommand() was throwing some unrelated exception, in case porting from
chrome to plain changed behavior of doCommand().
MozReview-Commit-ID: LOo8yN8jkZo
Possible issue: the previous version saved document.popupNode and
restored it after copying the image, and the new version does not
(because I don't know how). The test seems to pass anyway.
MozReview-Commit-ID: 7g0JCYxI7x8
--HG--
rename : editor/libeditor/tests/test_bug1140617.xul => editor/libeditor/tests/test_bug1140617.html
Possible issue: the previous version saved document.popupNode and
restored it after copying the image, and the new version does not
(because I don't know how). The test seems to pass anyway.
It seems I had to use doCommand instead of execCommand to carry out the
paste, presumably because of permissions differences between plain and
chrome mochitests.
MozReview-Commit-ID: CdPUCmEtgwO
--HG--
rename : editor/libeditor/tests/test_bug490879.xul => editor/libeditor/tests/test_bug490879.html
Filed bug 1299574 for the Android todo. (Chrome tests in this directory
are disabled for Android, so all this porting enables them.)
MozReview-Commit-ID: 6FAioabxq0a
--HG--
rename : editor/libeditor/tests/test_selection_move_commands.xul => editor/libeditor/tests/test_selection_move_commands.html
Fails in e10s. mrbkap said he has no idea why without debugging it
(comment 8 in bug).
MozReview-Commit-ID: 6vG0czg6Vpv
--HG--
extra : rebase_source : 1ef955889b331352870542b5362c8368c6ed290f
The .cpp files under editor/txmgr have a lot of unnecessary empty lines and they make reading the code more difficult because fewer lines can be displayed in screen. This patch removes such unnecessary lines and C like variable declarations at start of some methods because they also waste lines and make them unclear where is the first user of them.
MozReview-Commit-ID: GXGkdoLJ4Jw
--HG--
extra : rebase_source : 449e191553cff8c875565802d930abe2a6dba4a6
For conforming to our coding rules, |result| of nsresult variants should be renamed to |rv|.
MozReview-Commit-ID: Bk8CyLAnvXQ
--HG--
extra : rebase_source : dd3dc34a032f22abf3fd7f85556b47ffbeec55b2
SetDocumentTitleTransaction.cpp was written a long time ago. So, it doesn't use our modern coding style. Let's fix it.
MozReview-Commit-ID: LhgMbv8dqKm
When there is no title element, SetDocumentTitleTransaction::SetDomTitle() creates title element and try to insert it to the head element. However, it might be swapped during modifying existing title element or head element.
Therefore, after modifying the tree, SetDocumentTitleTransaction::SetDomTitle() should forget the retrieved head element and when it needs to refer current head element, it should retry to get the head element again.
MozReview-Commit-ID: 59BxEwrflye
For detecting regressions, SetDocumentTitleTransaction::SetDomTitle() should be tested.
The transaction is created only when nsIHTMLEditor::setDocumentTitle(). Therefore, it needs to be a chrome mochitest.
MozReview-Commit-ID: 4UjAJ8zNPBP
Currently, editor code uses following style (or similar style) in a lot of places:
if (foo)
{
}
else
{
}
This patch fixes this as conforming to our coding rules, i.e., it becomes:
if (foo) {
} else {
}
Additionally, this fixes other odd control statements in the files which include above issue because it's difficult to find following issues with searching the files:
* if (foo) bar;
* if (foo) { bar; }
* if (foo)
bar;
Finally, if it becomes much simpler than current code, this patch rewrites existing code with "early return style". But this case is only a few places because this is risky.
MozReview-Commit-ID: 2Gs26goWXrF
--HG--
extra : rebase_source : 603f9003a3566b3203bdeb27dc73ac33502d2853
In our coding rules, variable names of nsresult should be rv. Indeed, when you see |rv| in the code, you must assume that its type if nsresult.
However, a lot of code under editor/ uses |res| for the variables of nsresult. Let's replace |res| with |rv|.
And this patch improves following points:
1. When |rv| is set in both |if| and |else| block and they are check outside of them, this moves the check into each |if| and |else| block because even if the failure is notified with warning, you cannot see which case was performed and failed. This change makes it clear.
2. When |return rv;| returns non-error code because |rv| is checked with NS_ENSURE_SUCCESS() immediately before, setting replacing it with |return NS_OK;| is clearer.
3. Move declaration of |nsresult rv| into smaller scope as far as possible. This prevents setting rv to unexpected value and easier to check its value at reading the code.
MozReview-Commit-ID: 9MAqj7sFey3
--HG--
extra : rebase_source : 0fd316b851ea616b3a95d8c1afc111ff55e11993
NS_FOUND_TARGET is now declared as an error code. However, making it as a success code makes the code simpler.
First, this patch renames it to NS_SUCCESS_EDITOR_FOUND_TARGET because it's usual naming rule (according to the other declarations).
Next, FindTargetNode() should return it when a nest call of itself returns NS_SUCCESS_EDITOR_FOUND_TARGET as it does now.
Finally, removing the code overwriting NS_FOUND_TARGET with NS_OK from HTMLEditor::CreateDOMFragmentFromPaste() since it doesn't cause hitting NS_ENSURE_SUCCESS() and the variable, rv, will be overwritten with other method's result.
MozReview-Commit-ID: 6GgZptrXXQa
--HG--
extra : rebase_source : 79418fc83fb087e559221f895c59c7c334980456
When typing character, current selection node might be anonymous DIV, not text node. So even if plain text, we might not get it.
We should get text node correctly when using plain text editor.
MozReview-Commit-ID: LmfYa7BqZnC
--HG--
extra : rebase_source : d08c74c8cc5fdec4d19772f112e54a08b95afeb3
When pasting large image, it may cause OOM when generating base64 data. So we should use fallible allocator instead.
Also, base64 is ASCII, so we should use AppendASCIItoUTF16 instead of AppendUTF8toUTF16.
MozReview-Commit-ID: 8yWPxfEcEwv
--HG--
extra : rebase_source : 6c2c3144d4413017b4861443c945aeb0d6d995ef
We can assume that if middle button's click event on a link isn't consumed by any event handlers including system event group's, it will cause open new tab. With this assumption, we can avoid using setTimeout which causes random orange.
However, unfortunately, in e10s mode, the default is NOT consumed at window in bubbling phase but consumed at that time. So, when not working the link is expected, we cannot check Event.defaultPrevented. But fortunately, we can check if the page is loaded after that.
Note that for testing this, the test needs to check if an event handler which is either in default group or system group consumed a click event. However, this runs as mochitest-plain. Therefore, Event.defaultPrevented returns false if the event is consumed only in the system group's event listener. For avoiding this issue, this patch adds defaultPreventedInAnyGroups() into SpecialPowers. In SpecialPowers, Event.defaultPrevented is accessed from chrome context. Therefore, we can get the result what this test needs.
MozReview-Commit-ID: Cfn4lFR1dfI
--HG--
extra : rebase_source : 51feb768bd38f62cc19c2f4aecaaea0135190599
The new name makes the sense of the condition much clearer. E.g. compare:
NS_WARN_IF_FALSE(!rv.Failed());
with:
NS_WARNING_ASSERTION(!rv.Failed());
The new name also makes it clearer that it only has effect in debug builds,
because that's standard for assertions.
--HG--
extra : rebase_source : 886e57a9e433e0cb6ed635cc075b34b7ebf81853
The main renaming was generated with the following python script:
```
import sys
import re
CAMEL_CASE_REGEX = re.compile(r"(^|_|-)([A-Z])([A-Z]+)")
DISPLAY_REGEX = re.compile(r"\bNS_STYLE_DISPLAY_([^M][A-Z_]+)\b")
def to_camel_case(ident):
return re.sub(CAMEL_CASE_REGEX,
lambda m: m.group(2) + m.group(3).lower(), ident)
def constant_to_enum(constant):
return "StyleDisplay::" + to_camel_case(constant) + ("_" if constant == "NONE" else "")
def process_line(line):
return re.sub(DISPLAY_REGEX,
lambda m: constant_to_enum(m.group(1)), line)
lines = []
with open(sys.argv[1], "r") as f:
for line in f:
lines.append(process_line(line))
with open(sys.argv[1], "w") as f:
for line in lines:
f.write(line)
```
And the following shell commands:
```
find . -name '*.cpp' -exec python display.py {} \;
find . -name '*.h' -exec python display.py {} \;
```
MozReview-Commit-ID: 91xYCbLC2Vf
They are non-standard aliases for "DragEvent" and "KeyboardEvent" that
are not supported by any other UA, and we would like to drop support.
So first let's stop using them ourselves, so we can use telemetry to see
if any sites are using them.
MozReview-Commit-ID: ICC33ORa2st
CompositionTransaction::SetIMESelection() is also called when user redos the committed composition. In such case, it doesn't have ranges, but DoTransaction() tries to restore selection ranges with no ranges. That causes hiding caret because when there is no caret range in the ranges, SetIMESelection() hides the caret as IME requested.
So, for redo, SetIMESelection() shouldn't hide caret when there are no ranges (i.e., the composition was already committed).
Previously we supported insertParagraph as a synonym for formatBlock
"p", which is both useless and incompatible with all other browsers.
Edge's behavior doesn't look useful and looks redundant with insertHTML
(although it matches the name nicely, probably because they invented
the command). Blink/WebKit treat it the same as hitting Enter, which is
useful for cross-browser testing until we get synthesizeKey() in wpt.
At the same time, I added insertLineBreak, which Blink/WebKit support
with the same functionality as pressing Shift-Enter.
The new event.html failures are spurious -- we used to pass by mistake
because we didn't support insertlinebreak at all. insertlinebreak.html
has only new passes, no new failures, although it's not clear on the
diff.
MozReview-Commit-ID: 16oPcxXwGcj
Many HTMLEditRules methods use the pattern of
nsCOMPtr<nsIEditor> kungFuDeathGrip(mHTMLEditor);
at the beginning of the method, followed by using mHTMLEditor freely.
If Init() is then called on the editor, mHTMLEditor is set to null, so
it will crash. Other bad stuff will probably happen too.
MozReview-Commit-ID: gUtaTAQJIh
When deleting, we previously would only move the cursor back into the
previous block if the last leaf node was a text node, for some reason.
We should move into the previous block in other cases as well, like if
the leaf node is a collapsed <br>. (Probably it's not correct to move
backward into tables, but that already was happening if the table had
text at the end. There may be other cases where this is wrong.)
MozReview-Commit-ID: 8e0dTU3lNYO
If the user tries to insert text without moving the cursor, the
invisible break will become visible, which from the user's perspective
means an extra line break was inserted for no reason.
The IsVisBreak change here is a bit scary, because it may result in
unexpected behavior changes, but it seems to improve correctness. If it
turns out to cause problems, it can be added as a special case to
GetGoodSelPointForNode instead.
MozReview-Commit-ID: 7SRQYHYtJvF
When deleting, we previously would only move the cursor back into the
previous block if the last leaf node was a text node, for some reason.
We should move into the previous block in other cases as well, like if
the leaf node is a collapsed <br>. (Probably it's not correct to move
backward into tables, but that already was happening if the table had
text at the end. There may be other cases where this is wrong.)
MozReview-Commit-ID: 8e0dTU3lNYO
If the user tries to insert text without moving the cursor, the
invisible break will become visible, which from the user's perspective
means an extra line break was inserted for no reason.
The IsVisBreak change here is a bit scary, because it may result in
unexpected behavior changes, but it seems to improve correctness. If it
turns out to cause problems, it can be added as a special case to
GetGoodSelPointForNode instead.
MozReview-Commit-ID: 7SRQYHYtJvF
Bug 1268736 inadvertently put a new test before a skip-if line, which
makes the new test skipped instead of the preexisting one.
MozReview-Commit-ID: 20SuUc3IhiG
This patch is generated by the following commands (note: if you're running
using OS X's sed, which accepts slightly different flags, you'll have to
specify an actual backup suffix in -i, or use gsed from Homebrew):
hg stat -c \
| cut -c 3- \
| tr '\n' '\0' \
| xargs -0 -P 8 gsed --follow-symlinks 's/\bnsCSSProperty\b/nsCSSPropertyID/g' -i''
Then:
hg mv layout/style/nsCSSProperty.h layout/style/nsCSSPropertyID.h
... and finally, manually renaming nsCSSProperty in the include guard in
nsCSSProperty.h.
MozReview-Commit-ID: ZV6jyvmLfA
--HG--
rename : layout/style/nsCSSProperty.h => layout/style/nsCSSPropertyID.h
The merge from inbound to central conflicted with the merge from
autoland to central, it appears. Per tree rules, the commit from the
autoland repo wins and the inbound commit gets backed out.
CLOSED TREE
--HG--
extra : amend_source : 927e1cdfa8e55ccbd873d404d905caf6871c8c4f
extra : histedit_source : 07095868c3f767258e1d7d2645193bf4811b13bb%2Ca49ae5a28bf6e67298b6208ee9254c25a2539712
This patch is generated by the following commands (note: if you're running
using OS X's sed, which accepts slightly different flags, you'll have to
specify an actual backup suffix in -i, or use gsed from Homebrew):
hg stat -c \
| cut -c 3- \
| tr '\n' '\0' \
| xargs -0 -P 8 gsed --follow-symlinks 's/\bnsCSSProperty\b/nsCSSPropertyID/g' -i''
Then:
hg mv layout/style/nsCSSProperty.h layout/style/nsCSSPropertyID.h
... and finally, manually renaming nsCSSProperty in the include guard in
nsCSSProperty.h.
MozReview-Commit-ID: ZV6jyvmLfA
--HG--
rename : layout/style/nsCSSProperty.h => layout/style/nsCSSPropertyID.h
This patch makes most Run() declarations in subclasses of nsIRunnable have the
same form: |NS_IMETHOD Run() override|.
As a result of these changes, I had to add |override| to a couple of other
functions to satisfy clang's -Winconsistent-missing-override warning.
--HG--
extra : rebase_source : 815d0018b0b13329bb5698c410f500dddcc3ee12
nsIContent::GetDesiredIMEState sets IMEState::DISABLED, so IME doesn't work well.
Actually, DetachEditorFromWindow is called twice. One is from nsEditingSession::StartDocumentLoad, and another is from nsDocShell::FirePageHideNotification.
When navigating to next, OnStateChange(..., STATE_START) is called. Even if next page is external viewer such as launching another application, STAT_START is called. So even if launching external application, DetachEditorFromWindow is called. So it means that editor is detached from docshell.
nsIContent::GetDesiredIMEState uses nsIEditor, but editor is detached state, so it cannot get nsIEditor.
When navigating to next content on internel viewer such HTML, nsDocShell::CreateContentViewer is called, then FirePageHideNotification is called.
So it is unnecessary to call DetachEditorFromWindow from nsEditorSession. And its call causes this issue.
MozReview-Commit-ID: Lf5Rhzm1PNF
--HG--
extra : rebase_source : c452e9ea0fc01670b49cd76e17fb782aef3a5c20
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
Makoto Kato
Andi-Bogdan Postelnicu
Ryan VanderMeulen
Carsten "Tomcat" Book
Masayuki Nakano
Benjamin Smedberg
Boris Zbarsky
SkyLined
Gerald Squelart
Neerja Pancholi
Phil Ringnalda
Sebastian Hengst
Jessica Jong
Xidorn Quan
Geoff Brown
Aryeh Gregor
Jonathan Kew
Eric Rahm
Olli Pettay
Ehsan Akhgari
aceman
Gabor Krizsanits
Shing Lyu
Manish Goregaokar
Ting-Yu Lin
Thomas Wisniewski
Michael Layzell
Nicholas Nethercote
Emilio Cobos Álvarez
Ou Shinjo
Lee Salzman
Jonathan Chan
Gregory Szorc
Wes Kocher
Joel Maher
Kartikaya Gupta
David Zbarsky
Tom Tromey
Chris Peterson
Andrew McCreight
Jimmy Wang