There was a problem introduced by pull request #2600 when trying to select and copy text in a selectable text field.
The problem only occurs when the text field is in a modal window.
It was caused by the modal run loop that is present as an eventListener on the CPApplication when in modal mode. It will
force a bail out from the sendEvent: method in CPApplication when trying to handle the event. As the check for key
equivalent is moved down by the #2600 pull request it will never be allowed to handle a copy command from the browser
menu or key equivalent.
The solution is to allow the text field to handle the event if it is selectable. This will also allow the text selection
to be altered from the keyboard with keys like shift-left/right/up/down arrow. Combinations like shift-option arrow also
work for whole word selection.
When a textField is used in a tableView, setValue forThemeAttribute
should refer to state CPThemeStateTableDataView instead of
CPThemeStateNormal as #2744 is now more accurate on states.
Previosly, we unflagged ```CPTextFieldInputDidBlur``` and ```CPTextFieldInputResigning``` before
the call to removeChild. This resulted in DOM exceptions in Chrome under certain conditions.
See https://stackoverflow.com/questions/21926083/failed-to-execute-removechild-on-node for
why we need to unflag ```CPTextFieldInputDidBlur``` and ```CPTextFieldInputResigning``` only after removing the element.
This apply to token fields also but with the corresponding flags. Also token fields now have the same behavior as the text field when bluring etc.
Without this change, clicking the done button in iOS Safari would dismiss the virtual keyboard but then it would immediately come back (as we forced a refocus).
The fix is to no longer force a refocus since it turns out we don't need to anymore given another previous fix.
Previously, when double-clicking on a table cell to edit it, there was a possibility of a race condition. A refresh of the display was requested, then the run loop was passed through once. But it was possible for the display refresh to not be queued when the run loop was passed through, in which case the refresh would cancel the editing. Or at least I think that's what was happening. ;-)
This commit (hopefully) eliminates the race condition by synchronously refreshing the layout and display.
Made some miscellaneous formatting fixes as well.
Previously, we could only give a selector and a target for perform in the runLoop. Now we can give a block.
This feature is used in the CPTextField class. Previously, when we wanted to call a function at the end of the stack we used window.setTimeout, however due to HTML5 specifications this wasn't called just at the end of the stack but at least 4ms (more information here https://developer.mozilla.org/en-US/docs/Web/API/WindowTimers/setTimeout#Minimum_delay_and_timeout_nesting). Now we give a block to perform, and this block will be performed in the next runloop.
Unittest has been added in Tests/Foundation/CPRunLoopTest.j
Previously, when making a right click and when a cappuccino menu was not displayed, the system menu was displayed. Now we don't display this menu anymore as in cocoa. We only display when making a right click on a CPTextField.
Previously, the selection of a textField did not work as expected when the user did a right click or a drag even if the label was set to none selectable.
Now, with the css style user-select, a textField can only be selected if it is selectable and enable.
Credit to @primalmotion
This PR adds the support for baseWritingDirection in CPControl.
Support of nib2cib has been added as well.
Test app in Tests/Manual/CPTextFieldEditingStyleTest/
Previously, the nextValidKeyView was wrong when the views were in a scrollView. Cappuccino did not take in account the possibility of scrolling, the lowest views were considered as outside of the platformWindow.
Now, it works as cocoa! The nextValidKeyView is the good one in a scrollView.
This pull request fixes another issue as well. A CPTextField can now become firstResponder even if the textField is not visible (as in cocoa). Previously a jump of the (html)window occurred to the textField. Now, cappuccino will internally scroll if needed to the element, focus it and then go back to previous scrolling position.
When setting controlSize, CPTextfield height was forced to min-size height.
Now we check that the frame size is between the min and the max size. It allows to constrain
a CPControl to have a fixed height by specifying a min-size equivalent to the maxsize.
In CPTextField case, we only have a min-size which enable us to have a specific size.
Changes has been made in Aristo2 only.
This patch adds support for CPTextField with multiline content. It uses
a DOM textarea when needed, instead of DOM input.
It also disable the spellchecking, fixes a bug where the input element was not
correctly resized when the frame changed, and refactor some code
Previously, the text cursor of the CPTextField didn't take in account the content-inset. This raised issue with class as the CPComboBox, when the mouse was over the popUpButton, there was still the text cursor instead of the default one.
Now it works as in Cocoa.
Previously, when the cursor was hover a CPTextField the cursor was an arrow till we selected the textField.
Now when the cursor is hover a CPTextField, and if this textField is enabled and editable or selectable we show the selecting cursor. This is the default behavior in Cocoa as well.
Updated manual test Tests/Manual/CPTextField/
Previously, when hitting the backspace key on a none editable/enable field, this triggered the browser's back button.
Now it does not anymore.
All credits for @apajarita
Fixed#2189
Previously, when removing a view, Cappuccino didn't clean the notification center. The notification center kept in reference old views.
This PR fix this issue. When a CPView is added to a view, the methods _removeObservers and _addObservers are called. In these both methods we remove and add the observer to the notification center if needed. _removeObservers and _addObservers are called for the view and its subviews. These both methods are called through the method viewWillMoveToSuperview.
When a CPView is removed, we only call the method _removeObservers.
When a CPWindow is closed, we call the method _removeObservers on its contentView.
When a CPWindow is about to be opened, we call the method _removeObservers and _addObservers on its contentView.
Refs #1880
Refs #2024
Test app in Tests/Manual/AttachedSheet2/SheetWindowController.j
Didier KorthoudtandGitHub
Didier KorthoudtandGitHub
daboe01andGitHub
Martin CarlbergandGitHub
daniel
Alexander Ljungberg
Alexandre Wilhelm
Didier Korthoudt
Aparajita Fishman
Antoine Mercadal
Christophe Serafin