More wiki

website_and_docs/content/documentation/grid/components.en.md

@@ -52,7 +52,8 @@ By default, the Node auto-registers all browser drivers available on the path of
 the machine where it runs. It also creates one slot per available CPU for Chromium
 based browsers and Firefox. For Safari and Internet Explorer, only one slot is created.
 Through a specific configuration, it can run sessions in Docker containers or relay commands. 
-You can see more configuration details in the next [section]({{< ref "setting_up_your_own_grid.md" >}}).
+You can see more configuration details in 
+[setting up your own grid]({{< ref "getting_started.md" >}}).
 
 A Node only executes the received commands, it does not evaluate, make judgments,
 or control anything. The machines where the Node is running does not need to have
@@ -96,6 +97,6 @@ When starting the Grid in its fully distributed mode, the Event Bus is the first
 
 {{% alert title="Running your own Grid" color="primary" %}}
 Looking forward to using all these components and run your own Grid? 
-Head to the ["Setting up your own"]({{< ref "setting_up_your_own_grid.md" >}})
+Head to the ["Getting Started"]({{< ref "getting_started.md" >}})
 section to understand how to put all these pieces together. 
 {{% /alert %}}

website_and_docs/content/documentation/grid/components.ja.md

@@ -57,7 +57,8 @@ By default, the Node auto-registers all browser drivers available on the path of
 the machine where it runs. It also creates one slot per available CPU for Chromium
 based browsers and Firefox. For Safari and Internet Explorer, only one slot is created.
 Through a specific configuration, it can run sessions in Docker containers or relay commands.
-You can see more configuration details in the next [section]({{< ref "setting_up_your_own_grid.md" >}}).
+You can see more configuration details in
+[setting up your own grid]({{< ref "getting_started.md" >}}).
 
 ノードは受信したコマンドを実行するだけで、評価、判断、制御は行いません。
 ノードが実行されているマシンは、他のコンポーネントと同じオペレーティングシステムを持つ必要はありません。
@@ -99,6 +100,6 @@ When starting the Grid in its fully distributed mode, the Event Bus is the first
 
 {{% alert title="Running your own Grid" color="primary" %}}
 Looking forward to using all these components and run your own Grid?
-Head to the ["Setting up your own"]({{< ref "setting_up_your_own_grid.md" >}})
+Head to the ["Getting Started"]({{< ref "getting_started.md" >}})
 section to understand how to put all these pieces together.
 {{% /alert %}}

website_and_docs/content/documentation/grid/components.pt-br.md

@@ -59,7 +59,8 @@ By default, the Node auto-registers all browser drivers available on the path of
 the machine where it runs. It also creates one slot per available CPU for Chromium
 based browsers and Firefox. For Safari and Internet Explorer, only one slot is created.
 Through a specific configuration, it can run sessions in Docker containers or relay commands.
-You can see more configuration details in the next [section]({{< ref "setting_up_your_own_grid.md" >}}).
+You can see more configuration details in
+[setting up your own grid]({{< ref "getting_started.md" >}}).
 
 Um Nó apenas executa os comandos recebidos, não avalia, não faz julgamentos,
 ou controlar qualquer coisa. As máquinas onde o Nó está rodando não precisam ter
@@ -102,6 +103,6 @@ When starting the Grid in its fully distributed mode, the Event Bus is the first
 
 {{% alert title="Running your own Grid" color="primary" %}}
 Looking forward to using all these components and run your own Grid?
-Head to the ["Setting up your own"]({{< ref "setting_up_your_own_grid.md" >}})
+Head to the ["Getting Started"]({{< ref "getting_started.md" >}})
 section to understand how to put all these pieces together.
 {{% /alert %}}

website_and_docs/content/documentation/grid/components.zh-cn.md

@@ -60,7 +60,7 @@ aliases: [
 只创建一个插槽. 
 通过特定的配置,
 它可以在Docker容器或中继命令中运行会话. 
-您可以在下一 [章节]({{< ref "setting_up_your_own_grid.md" >}}) 
+您可以在下一 [章节]({{< ref "getting_started.md" >}}) 
 中看到更多配置详细信息.
 
 节点仅执行接收到的命令, 
@@ -110,6 +110,6 @@ aliases: [
 
 {{% alert title="运行你自己的Grid" color="primary" %}}
 期待使用所有组件并运行自己的Grid? 
-前往 ["配置自己的服务网格"]({{< ref "setting_up_your_own_grid.md" >}}) ,
+前往 ["配置自己的服务网格"]({{< ref "getting_started.md" >}}) ,
 了解如何将所有零件组合在一起.
 {{% /alert %}}

website_and_docs/content/documentation/grid/getting_started.en.md

@@ -12,7 +12,7 @@ aliases: [
 
 ## Grid roles
 
-Several [components]({{< ref "components_of_a_grid.md" >}}) compose a Selenium Grid. Depending 
+Several [components]({{< ref "components.md" >}}) compose a Selenium Grid. Depending 
 on your needs, you can start each one of them on its own, or a few at the same time by using a
 Grid role.
 

website_and_docs/content/documentation/grid/getting_started.ja.md

@@ -2,6 +2,7 @@
 title: "独自のグリッドを設定する"
 linkTitle: "独自のグリッドを設定する"
 weight: 2
+needsTranslation: true
 description: >
   Instructions, step by step, showing how to run a simple Selenium Grid.
 aliases: [
@@ -10,18 +11,9 @@ aliases: [
 ]
 ---
 
-{{% pageinfo color="warning" %}}
-<p class="lead">
-   <i class="fas fa-language display-4"></i> 
-   Page being translated from 
-   English to Japanese. Do you speak Japanese? Help us to translate
-   it by sending us pull requests!
-</p>
-{{% /pageinfo %}}
-
 ## Grid roles
 
-Several [components]({{< ref "components_of_a_grid.md" >}}) compose a Selenium Grid. Depending
+Several [components]({{< ref "components.md" >}}) compose a Selenium Grid. Depending
 on your needs, you can start each one of them on its own, or a few at the same time by using a
 Grid role.
 

website_and_docs/content/documentation/grid/getting_started.pt-br.md

@@ -2,6 +2,7 @@
 title: "Configurando a sua"
 linkTitle: "Configurando a sua"
 weight: 2
+needsTranslation: true
 description: >
   Instructions, step by step, showing how to run a simple Selenium Grid.
 aliases: [
@@ -10,18 +11,9 @@ aliases: [
 ]
 ---
 
-{{% pageinfo color="warning" %}}
-<p class="lead">
-   <i class="fas fa-language display-4"></i> 
-   Page being translated from 
-   English to Portuguese. Do you speak Portuguese? Help us to translate
-   it by sending us pull requests!
-</p>
-{{% /pageinfo %}}
-
 ## Grid roles
 
-Several [components]({{< ref "components_of_a_grid.md" >}}) compose a Selenium Grid. Depending
+Several [components]({{< ref "components.md" >}}) compose a Selenium Grid. Depending
 on your needs, you can start each one of them on its own, or a few at the same time by using a
 Grid role.
 

website_and_docs/content/documentation/grid/getting_started.zh-cn.md

@@ -2,6 +2,7 @@
 title: "Selenium Grid快速起步"
 linkTitle: "快速起步"
 weight: 2
+needsTranslation: true
 description: >
   一步一步地说明如何运行简单的Selenium Grid.
 aliases: [
@@ -10,18 +11,9 @@ aliases: [
 ]
 ---
 
-{{% pageinfo color="warning" %}}
-<p class="lead">
-   <i class="fas fa-language display-4"></i> 
-   Page being translated from 
-   English to Chinese. Do you speak Chinese? Help us to translate
-   it by sending us pull requests!
-</p>
-{{% /pageinfo %}}
-
 ## Grid roles
 
-Several [components]({{< ref "components_of_a_grid.md" >}}) compose a Selenium Grid. Depending
+Several [components]({{< ref "components.md" >}}) compose a Selenium Grid. Depending
 on your needs, you can start each one of them on its own, or a few at the same time by using a
 Grid role.
 

website_and_docs/content/documentation/ie_driver_server.pt-br.md → website_and_docs/content/documentation/ie_driver_server/_index.en.md

@@ -5,6 +5,7 @@ weight: 8
 description: >
     The Internet Explorer Driver is a standalone server that implements the WebDriver specification.
 ---
+This documentation previously located [on the wiki](https://github.com/SeleniumHQ/selenium/wiki/InternetExplorerDriver-Internals) \
 
 The `InternetExplorerDriver` is a standalone server which implements WebDriver's wire protocol.
 This driver has been tested with IE 11, and on Windows 10. It might work with older versions

website_and_docs/content/documentation/ie_driver_server/internals.en.md

@@ -0,0 +1,46 @@
+---
+title: "Internet Explorer Driver Internals"
+linkTitle: "Internals"
+weight: 2
+description: >
+    More detailed information on the IE Driver.
+---
+
+## Client Code Into the Driver
+
+We use the W3C WebDriver protocol to communicate with a local instance of an HTTP server. This greatly simplifies the implementation of the language-specific code, and minimzes the number of entry points into the C++ DLL that must be called using a native-code interop technology such as [JNA](https://jna.dev.java.net/), [ctypes](http://docs.python.org/library/ctypes.html), [pinvoke](http://msdn.microsoft.com/en-us/library/aa446536.aspx) or [DL](http://www.ruby-doc.org/stdlib/libdoc/dl/rdoc/index.html).
+
+### Memory Management
+
+The IE driver utilizes the Active Template Library (ATL) to take advantage of its implementation of smart pointers to COM objects. This makes reference counting and cleanup of COM objects much easier.
+
+## Why Do We Require Protected Mode Settings Changes?
+
+IE 7 on Windows Vista introduced the concept of Protected Mode, which allows for some measure of protection to the underlying Windows OS when browsing. The problem is that when you manipulate an instance of IE via COM, and you navigate to a page that would cause a transition into or out of Protected Mode, IE requires that another browser session be created. This will orphan the COM object of the previous session, not allowing you to control it any longer.
+
+In IE 7, this will usually manifest itself as a new top-level browser window; in IE 8, a new IExplore.exe process will be created, but it will usually (not always!) seamlessly attach it to the existing IE top-level frame window. Any browser automation framework that drives IE externally (as opposed to using a WebBrowser control) will run into these problems.
+
+In order to work around that problem, we dictate that to work with IE, all zones must have the same Protected Mode setting. As long as it's on for all zones, or off for all zones, we can prevent the transistions to different Protected Mode zones that would invalidate our browser object. It also allows users to continue to run with UAC turned on, and to run securely in the browser if they set Protected Mode "on" for all zones.
+
+In earlier releases of the IE driver, if the user's Protected Mode settings were not correctly set, we would launch IE, and the process would simply hang until the HTTP request timed out. This was suboptimal, as it gave no indication what needed to be set. Erring on the side of caution, we do not modify the user's Protected Mode settings. Current versions, however check that the Protected Mode settings are properly set, and will return an error response if they are not.
+
+## Keyboard and Mouse Input
+
+Key files: [interactions.cpp](https://github.com/SeleniumHQ/selenium/blob/master/cpp/webdriver-interactions/interactions.cpp)
+
+There are two ways that we could simulate keyboard and mouse input. The first way, which is used in parts of webdriver, is to synthesize events on the DOM. This has a number of drawbacks, since each browser (and version of a browser) has its own unique quirks; to model each of these is a demanding task, and impossible to get completely right (for example, it's hard to tell what `window.selection` should be and this is a read-only property on some browsers) The alternative approach is to synthesize keyboard and mouse input at the OS level, ideally without stealing focus from the user (who tends to be doing other things on their computer as long-running webdriver tests run)
+
+The code for doing this is in [interactions.cpp](https://github.com/SeleniumHQ/selenium/blob/master/cpp/webdriver-interactions/interactions.cpp) The key thing to note here is that we use PostMessages to push window events on to the message queue of the IE instance. Typing, in particular, is interesting: we only send the "keydown" and "keyup" messages. The "keypress" event is created if necessary by IE's internal event processing. Because the key press event is not always generated (for example, not every character is printable, and if the default event bubbling is cancelled, listeners don't see the key press event) we send a "probe" event in after the key down. Once we see that this has been processed, we know that the key press event is on the stack of events to be processed, and that it is safe to send the key up event. If this was not done, it is possible for events to fire in the wrong order, which is definitely sub-optimal.
+
+# Working On the InternetExplorerDriver
+
+Currently, there are tests that will run for the InternetExplorerDriver in all languages (Java, C#, Python, and Ruby), so you should be able to test your changes to the native code no matter what language you're comfortable working in from the client side. For working on the C++ code, you'll need Visual Studio 2010 Professional or higher. Unfortunately, the C++ code of the driver uses ATL to ease the pain of working with COM objects, and ATL is not supplied with Visual C++ 2010 Express Edition.  If you're using Eclipse, the process for making and testing modifications is:
+
+1. Edit the C++ code in VS.
+1. Build the code to ensure that it compiles
+1. Do a complete rebuild when you are ready to run a test. This will cause the created DLL to be copied to the right place to allow its use in Eclipse
+1. Load Eclipse (or some other IDE, such as Idea)
+1. Edit the `SingleTestSuite` so that it is `usingDriver(IE)`
+1. Create a JUnit run configuration that uses the "webdriver-internet-explorer" project. If you don't do this, the test won't work at all, and there will be a somewhat cryptic error message on the console.
+
+Once the basic setup is done, you can start working on the code pretty quickly. You can attach to the process you execute your code from using Visual Studio (from the Debug menu, select Attach to Process...).

website_and_docs/content/documentation/ie_driver_server/internals.ja.md

@@ -0,0 +1,47 @@
+---
+title: "Internet Explorer Driver Internals"
+linkTitle: "Internals"
+weight: 2
+needsTranslation: true
+description: >
+    More detailed information on the IE Driver.
+---
+
+## Client Code Into the Driver
+
+We use the W3C WebDriver protocol to communicate with a local instance of an HTTP server. This greatly simplifies the implementation of the language-specific code, and minimzes the number of entry points into the C++ DLL that must be called using a native-code interop technology such as [JNA](https://jna.dev.java.net/), [ctypes](http://docs.python.org/library/ctypes.html), [pinvoke](http://msdn.microsoft.com/en-us/library/aa446536.aspx) or [DL](http://www.ruby-doc.org/stdlib/libdoc/dl/rdoc/index.html).
+
+### Memory Management
+
+The IE driver utilizes the Active Template Library (ATL) to take advantage of its implementation of smart pointers to COM objects. This makes reference counting and cleanup of COM objects much easier.
+
+## Why Do We Require Protected Mode Settings Changes?
+
+IE 7 on Windows Vista introduced the concept of Protected Mode, which allows for some measure of protection to the underlying Windows OS when browsing. The problem is that when you manipulate an instance of IE via COM, and you navigate to a page that would cause a transition into or out of Protected Mode, IE requires that another browser session be created. This will orphan the COM object of the previous session, not allowing you to control it any longer.
+
+In IE 7, this will usually manifest itself as a new top-level browser window; in IE 8, a new IExplore.exe process will be created, but it will usually (not always!) seamlessly attach it to the existing IE top-level frame window. Any browser automation framework that drives IE externally (as opposed to using a WebBrowser control) will run into these problems.
+
+In order to work around that problem, we dictate that to work with IE, all zones must have the same Protected Mode setting. As long as it's on for all zones, or off for all zones, we can prevent the transistions to different Protected Mode zones that would invalidate our browser object. It also allows users to continue to run with UAC turned on, and to run securely in the browser if they set Protected Mode "on" for all zones.
+
+In earlier releases of the IE driver, if the user's Protected Mode settings were not correctly set, we would launch IE, and the process would simply hang until the HTTP request timed out. This was suboptimal, as it gave no indication what needed to be set. Erring on the side of caution, we do not modify the user's Protected Mode settings. Current versions, however check that the Protected Mode settings are properly set, and will return an error response if they are not.
+
+## Keyboard and Mouse Input
+
+Key files: [interactions.cpp](https://github.com/SeleniumHQ/selenium/blob/master/cpp/webdriver-interactions/interactions.cpp)
+
+There are two ways that we could simulate keyboard and mouse input. The first way, which is used in parts of webdriver, is to synthesize events on the DOM. This has a number of drawbacks, since each browser (and version of a browser) has its own unique quirks; to model each of these is a demanding task, and impossible to get completely right (for example, it's hard to tell what `window.selection` should be and this is a read-only property on some browsers) The alternative approach is to synthesize keyboard and mouse input at the OS level, ideally without stealing focus from the user (who tends to be doing other things on their computer as long-running webdriver tests run)
+
+The code for doing this is in [interactions.cpp](https://github.com/SeleniumHQ/selenium/blob/master/cpp/webdriver-interactions/interactions.cpp) The key thing to note here is that we use PostMessages to push window events on to the message queue of the IE instance. Typing, in particular, is interesting: we only send the "keydown" and "keyup" messages. The "keypress" event is created if necessary by IE's internal event processing. Because the key press event is not always generated (for example, not every character is printable, and if the default event bubbling is cancelled, listeners don't see the key press event) we send a "probe" event in after the key down. Once we see that this has been processed, we know that the key press event is on the stack of events to be processed, and that it is safe to send the key up event. If this was not done, it is possible for events to fire in the wrong order, which is definitely sub-optimal.
+
+# Working On the InternetExplorerDriver
+
+Currently, there are tests that will run for the InternetExplorerDriver in all languages (Java, C#, Python, and Ruby), so you should be able to test your changes to the native code no matter what language you're comfortable working in from the client side. For working on the C++ code, you'll need Visual Studio 2010 Professional or higher. Unfortunately, the C++ code of the driver uses ATL to ease the pain of working with COM objects, and ATL is not supplied with Visual C++ 2010 Express Edition.  If you're using Eclipse, the process for making and testing modifications is:
+
+1. Edit the C++ code in VS.
+1. Build the code to ensure that it compiles
+1. Do a complete rebuild when you are ready to run a test. This will cause the created DLL to be copied to the right place to allow its use in Eclipse
+1. Load Eclipse (or some other IDE, such as Idea)
+1. Edit the `SingleTestSuite` so that it is `usingDriver(IE)`
+1. Create a JUnit run configuration that uses the "webdriver-internet-explorer" project. If you don't do this, the test won't work at all, and there will be a somewhat cryptic error message on the console.
+
+Once the basic setup is done, you can start working on the code pretty quickly. You can attach to the process you execute your code from using Visual Studio (from the Debug menu, select Attach to Process...).