6ee7e7bd92b02de63717b0f70502d47cbdb7d5ed: Bug 1399800 - integrate python-test compatible unit tests r?ahal, jmaher draft
Ionut Goldan <igoldan@mozilla.com> - Mon, 16 Oct 2017 16:49:26 +0300 - rev 680869
Push 84659 by bmo:igoldan@mozilla.com at Mon, 16 Oct 2017 14:17:29 +0000
Bug 1399800 - integrate python-test compatible unit tests r?ahal, jmaher MozReview-Commit-ID: II6vt96s6CJ
5ea27a039fd9e89c5d2cb176e2916a051935173c: Bug 1408795 - Disable Eclipse CDT's binary parser. r=botond draft
Jonathan Watt <jwatt@jwatt.org> - Mon, 16 Oct 2017 10:32:00 +0100 - rev 680868
Push 84658 by jwatt@jwatt.org at Mon, 16 Oct 2017 14:15:24 +0000
Bug 1408795 - Disable Eclipse CDT's binary parser. r=botond By default Eclipse CDT will scan the source tree for binaries so that it can add those binaries to the list of things that it can run. This scanning is a constant interuption and can last several seconds. Besides that, it's currently useless for our setup since the only binaries that we're interested in running are in the object directory (which it doesn't scan), and those are set up during project generation. (The only binaries found in the source tree are a couple of uninteresting bundled libraries.) MozReview-Commit-ID: BYO2DXGsqk4
b189d42e8ed068c6207c4f94a460aed549a511c2: Bug 1408795 - Disable Eclipse CDT's "scalability" mode for files with fewer than 15,000 lines. r=botond draft
Jonathan Watt <jwatt@jwatt.org> - Mon, 16 Oct 2017 10:19:17 +0100 - rev 680867
Push 84658 by jwatt@jwatt.org at Mon, 16 Oct 2017 14:15:24 +0000
Bug 1408795 - Disable Eclipse CDT's "scalability" mode for files with fewer than 15,000 lines. r=botond By default, scalability mode is activated for files with 5,000 lines or more. There are quite a few C++ files with more than 5,000 lines, and Eclipse seems to work fine with them with scalability mode turned off (even nsCSSFrameConstructor.cpp which is over 13,000 lines long). Increasing the number of lines before scalability mode is enabled allows Eclipse to handle these files better. MozReview-Commit-ID: INCd7XXHwm
ea8f01b4a59f49f6b899c0774ba4fd1250f4c6d4: Bug 1408795 - Have Eclipse CDT treat Objective-C files as C++. r=botond draft
Jonathan Watt <jwatt@jwatt.org> - Mon, 16 Oct 2017 10:09:00 +0100 - rev 680866
Push 84658 by jwatt@jwatt.org at Mon, 16 Oct 2017 14:15:24 +0000
Bug 1408795 - Have Eclipse CDT treat Objective-C files as C++. r=botond Without this setting, eclipse will refuse to open Objective-C files (it will defer to an external editor). Adding *.mm to the file types that are treated as C++ allows Eclipse to open them, and to provide some code assistance for the bits of the files that it can understand. MozReview-Commit-ID: FRGcvqf2KFs
4252f8350a9833081354b86f02f37b19ca02fd58: Bug 1408795 - Enable Eclipse CDT's "Refresh using native hooks or polling" setting. r=botond draft
Jonathan Watt <jwatt@jwatt.org> - Mon, 16 Oct 2017 09:39:01 +0100 - rev 680865
Push 84658 by jwatt@jwatt.org at Mon, 16 Oct 2017 14:15:24 +0000
Bug 1408795 - Enable Eclipse CDT's "Refresh using native hooks or polling" setting. r=botond This setting allows Eclipse to notice when files it has open are changed externally (such as by hg/git, for example). It can then update the contents that it has for the open files, avoiding annoying issues such as saving changes after an `hg pull -u` resulting in either "Resource is out of sync" errors or else clobbering of the changes hg made to files. MozReview-Commit-ID: F3zvEMR42ZM
b2164332dc2295f120005d4b51ef02cd3263cbc0: Bug 1408795 - Prevent Eclipse CDT's blocking "Welcome" screen from showing on startup. r=botond draft
Jonathan Watt <jwatt@jwatt.org> - Mon, 16 Oct 2017 09:20:42 +0100 - rev 680864
Push 84658 by jwatt@jwatt.org at Mon, 16 Oct 2017 14:15:24 +0000
Bug 1408795 - Prevent Eclipse CDT's blocking "Welcome" screen from showing on startup. r=botond The blocking Welcome screen is quite confusing for a new user. It is not clear where to find the Mozilla stuff they expect to see when opening Eclipse, or that the user needs to close the entire content area to get to it. Besides that the screen isn't very useful for Mozilla people who will find more relevant help from searching the online documentation, and who won't be creating new projects in the generated workspace, etc. MozReview-Commit-ID: BaUFpQBFCOm
bf7b131a735ea0f0d87f55702fbb92f4e8d9e47e: Bug 1408795 - Turn off Eclipse CDT's "Ensure newline at the end of file" setting. r=botond draft
Jonathan Watt <jwatt@jwatt.org> - Mon, 16 Oct 2017 09:17:32 +0100 - rev 680863
Push 84658 by jwatt@jwatt.org at Mon, 16 Oct 2017 14:15:24 +0000
Bug 1408795 - Turn off Eclipse CDT's "Ensure newline at the end of file" setting. r=botond The setting to ensure that there is a newline at the end of files when they are saved is very annoying. Besides adding unnecessary and unexpected cruft to diffs, some parts of the codebase (some of the reftest directories for example) have a policy of NOT having a newline at the end of their files. MozReview-Commit-ID: JwrI6nL40Bj
cad76bf1da23fd54a3a13b6a6f180982d692864a: Bug 1408810 - Get the Eclipse CDT code formatter working again. r=botond draft
Jonathan Watt <jwatt@jwatt.org> - Mon, 16 Oct 2017 02:27:20 +0100 - rev 680862
Push 84658 by jwatt@jwatt.org at Mon, 16 Oct 2017 14:15:24 +0000
Bug 1408810 - Get the Eclipse CDT code formatter working again. r=botond This makes us write the code formatter settings into the workspace settings directory instead of the project settings directory. This is preferable since when users make settings changes they are more likely to work with the workspace settings, so we should put them there. Putting them there also fixes a bug whereby the calls to _write_noindex/_remove_noindex would overwrite the formatter settings file shortly after it had been created. To get the formatter to show up in the UI we also need to set the formatter settings as a one line pref value in the CDT UI settings. This duplication is what Eclipse does when a new formatter is manually added, and it's necessary to get the formatter working correctly.
ad7573f123992d709ea88e037d9a41ca80645432: Bug 1379560 - Part 2 - Add support for custom default permissions in SitePermissions.jsm. r=Paolo draft
Johann Hofmann <jhofmann@mozilla.com> - Mon, 10 Jul 2017 23:33:37 +0200 - rev 680861
Push 84657 by bmo:jhofmann@mozilla.com at Mon, 16 Oct 2017 14:06:38 +0000
Bug 1379560 - Part 2 - Add support for custom default permissions in SitePermissions.jsm. r=Paolo Part 1 added support for changing default permissions via pref. This patch adds support in the frontend code, which is required to actually make it work for most permission prompts. This patch introduces the concept of SitePermissions.PROMPT (which already exists in the permission manager) to distinguish between the default UNKNOWN state and the explicit PROMPT state. They both have the same effect (always asking the user for confirmation). MozReview-Commit-ID: 2Gg9uwigter
48a1a26e515b435d333c6aaa911bd7cef0505d4c: Bug 1379560 - Part 1 - Add a default permission pref in the permission manager. r=mystor,Paolo draft
Johann Hofmann <jhofmann@mozilla.com> - Mon, 10 Jul 2017 23:13:43 +0200 - rev 680860
Push 84657 by bmo:jhofmann@mozilla.com at Mon, 16 Oct 2017 14:06:38 +0000
Bug 1379560 - Part 1 - Add a default permission pref in the permission manager. r=mystor,Paolo This patch enables support for setting prefs with the pattern permissions.default.* to provide a custom default permission for arbitrary permission types in nsPermissionManager. The previous default of UNKNOWN_ACTION is honored if no pref is set. A default value is provided if no permission entry can be found in the db. Accordingly, the patch does not affect the behavior of functions that return permission objects from the db such as GetPermissionObject, which returns null if no entry was found. MozReview-Commit-ID: 3JECI6kXqGf
140c775eb23475d19fe793b93500d14610e6fc73: Bug 1400256 - Adapt actions for implicitly unmarshaled elements. r?automatedtester draft
Andreas Tolfsen <ato@sny.no> - Mon, 09 Oct 2017 19:55:27 +0100 - rev 680859
Push 84656 by bmo:ato@sny.no at Mon, 16 Oct 2017 14:02:26 +0000
Bug 1400256 - Adapt actions for implicitly unmarshaled elements. r?automatedtester Since web element references are now implicitly unmarshaled when they are passed to the content frame script, there is no need for the actions module to check that the element origin is a reference and try to look it up from the known element store. MozReview-Commit-ID: 3BGBIBQMtR3
257efe81b35f1db6b86b0957e6af76ccc316a257: Bug 1400256 - Marshal IPC messages to and from frame script. r?whimboo draft
Andreas Tolfsen <ato@sny.no> - Thu, 05 Oct 2017 17:57:17 +0100 - rev 680858
Push 84656 by bmo:ato@sny.no at Mon, 16 Oct 2017 14:02:26 +0000
Bug 1400256 - Marshal IPC messages to and from frame script. r?whimboo MozReview-Commit-ID: BTDQDvu2pVE
92ec306cef4632f4ecc0cc45636cdcbccaa5f43e: Bug 1400256 - Recognise web element references in evaluate.toJSON. r?whimboo draft
Andreas Tolfsen <ato@sny.no> - Thu, 05 Oct 2017 17:55:52 +0100 - rev 680857
Push 84656 by bmo:ato@sny.no at Mon, 16 Oct 2017 14:02:26 +0000
Bug 1400256 - Recognise web element references in evaluate.toJSON. r?whimboo MozReview-Commit-ID: BvKHGzsF0ie
6c2700aad60ba4ba604ed262d392952700ff2008: Bug 1400256 - Use WebElement for marshaling web elements in evaluate.fromJSON. r?whimboo draft
Andreas Tolfsen <ato@sny.no> - Thu, 05 Oct 2017 17:55:31 +0100 - rev 680856
Push 84656 by bmo:ato@sny.no at Mon, 16 Oct 2017 14:02:26 +0000
Bug 1400256 - Use WebElement for marshaling web elements in evaluate.fromJSON. r?whimboo MozReview-Commit-ID: KwjZ60WlyKp
d7011dca867526a107124442103babbfdcd919db: Bug 1400256 - Make element.Store work with web elements. r?whimboo draft
Andreas Tolfsen <ato@sny.no> - Thu, 05 Oct 2017 18:01:35 +0100 - rev 680855
Push 84656 by bmo:ato@sny.no at Mon, 16 Oct 2017 14:02:26 +0000
Bug 1400256 - Make element.Store work with web elements. r?whimboo MozReview-Commit-ID: AitZAYFtpoF
128a046e3d97adfaa454ff3d36573571d898ba37: Bug 1400256 - Use web element references in action tests. r?whimboo draft
Andreas Tolfsen <ato@sny.no> - Mon, 09 Oct 2017 16:40:11 +0100 - rev 680854
Push 84656 by bmo:ato@sny.no at Mon, 16 Oct 2017 14:02:26 +0000
Bug 1400256 - Use web element references in action tests. r?whimboo MozReview-Commit-ID: 2D3PdriqjYz
e1d6eb435c74772ff6d9f639c5877badf1061fc5: Bug 1400256 - Drop unused arguments to evaluate.toJSON/fromJSON. r?whimboo draft
Andreas Tolfsen <ato@sny.no> - Thu, 05 Oct 2017 17:53:25 +0100 - rev 680853
Push 84656 by bmo:ato@sny.no at Mon, 16 Oct 2017 14:02:26 +0000
Bug 1400256 - Drop unused arguments to evaluate.toJSON/fromJSON. r?whimboo MozReview-Commit-ID: 8q0PK3M4rif
f2abe4f816c685fbe2c3f081b69bd35aa682c584: Bug 1400256 - Serialise IPC messages with evaluate.toJSON. r?whimboo draft
Andreas Tolfsen <ato@sny.no> - Thu, 05 Oct 2017 17:50:34 +0100 - rev 680852
Push 84656 by bmo:ato@sny.no at Mon, 16 Oct 2017 14:02:26 +0000
Bug 1400256 - Serialise IPC messages with evaluate.toJSON. r?whimboo Instead of having commands serialising their own JSON-safe messages when communicating with the content frame script, this patch changes the AsyncMessageChannel to use evaluate.toJSON. MozReview-Commit-ID: LmAVGEjqMTB
10c781bc59aac3d3d50669d77e8db15fc41d225b: Bug 1400256 - Use WebElement.generateUUID to make session ID. r?whimboo draft
Andreas Tolfsen <ato@sny.no> - Thu, 05 Oct 2017 17:11:26 +0100 - rev 680851
Push 84656 by bmo:ato@sny.no at Mon, 16 Oct 2017 14:02:26 +0000
Bug 1400256 - Use WebElement.generateUUID to make session ID. r?whimboo MozReview-Commit-ID: FuYeCDySLu
e9fa78b1f19cfb6edf5bdea1eb5967d5afad45ef: Bug 1400256 - Remove element.isWebElementReference. r?whimboo draft
Andreas Tolfsen <ato@sny.no> - Thu, 05 Oct 2017 17:07:48 +0100 - rev 680850
Push 84656 by bmo:ato@sny.no at Mon, 16 Oct 2017 14:02:26 +0000
Bug 1400256 - Remove element.isWebElementReference. r?whimboo Remove element.isWebElementReference in favour of WebElement.isReference. MozReview-Commit-ID: IOqx7XMUfCu
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip