Restrictions Associated with Environment
Caret position when focus moves into MaskEdit
The position of a caret will move to the end of text when focus moves into the MaskEdit component. This problem occurs in the iOS environment when the type property of the MaskEdit is set to "string".
RP | Written in | Description |
---|---|---|
69265 | 2016-09-13 | In the iOS environment, a device will call a command to display a keypad when focus moves into the editable field of a component. At this point, iOS will change the value of the type property of the DOM Input Text object and then renew the text. This process causes the caret to move to the end of the text. Although we can change the caret’s position forcibly, we do not do so for fear of deterioration in performance. |
Restriction related to file download when applying Enhanced Protected Mode.
If you check the Enhanced Protected Mode option in IE10 or later, the download path will be virtualized so that files will be downloaded only to a specific folder while other Windows folders are protected. In this case, therefore, users are prevented from designating their own download paths.
RP | Written in | Description |
---|---|---|
71778 | 2017-02-13 | The Enhanced Protected Mode option is selected by users in IE10 or later. Therefore, you can advise users to change the option if necessary. |
Background image of Menu fails to be loaded
The background image of a Menu component will not be displayed when the application is loaded in Firefox. This problem occurs when you specify an image file as the value of image, a subproperty of the itembackground property of the Menu, while setting the repeat property to "stretch".
RP | Written in | Description |
---|---|---|
71855 | 2017-02-17 | This is a restriction created by the rendering engine of Firefox. The background image will be displayed if you refresh the relevant window of the web browser. |
setFocus method fails to move caret
In Microsoft Edge, a caret will not move while the focus moves when the setFocus method is called. This problem occurs to a component with an editable field when setFocus is called within the handler of the onkillfocus event of the same component.
Let us assume that there are two Edit components. With focus in the first component (Edit00), its onkillfocus will occur if you click the editable field of the second component (Edit01). Afterward, the focus will go back to the first Edit while the caret will stay in the second Edit.
this.Edit00_onkillfocus = function(obj:Edit, e:nexacro.KillFocusEventInfo) { if(obj.value == null) obj.setFocus(); }
RP | Written in | Description |
---|---|---|
71955 | 2017-02-23 | This is a bug that Microsoft Edge is responsible for. |
appendItem method of FileUpload fails to be executed
If you call the appendItem method of a FileUpload component repeatedly in the Safari browser, the method will not work from the second instance of calling.
RP | Written in | Description |
---|---|---|
72002 | 2017-02-28 | This is a bug caused by the Safari browser running in the Windows environment. |
Restriction on search for text value in editable field
In Internet Explorer, you cannot search for the text value entered in the editable field of a component by using the search feature of the browser.
RP | Written in | Description |
---|---|---|
72123 | 2017-03-09 | This is a restriction created by Internet Explorer. |
Windows increasingly takes up memory when WebBrowser is created and deleted repeatedly
Windows will increasingly take up memory if you repeat the creation and deletion of a WebBrowser component when running the Nexacro Browser. Consequently, your application will not perform as well as it is designed.
One example is a case where you link a Div component to a Form that contains a WebBrowser by specifying the Form as the value of the Div's url property. Whenever you change the value of url, the creation and deletion of a WebBrowser are repeated, increasing the use of memory.
RP | Written in | Description |
---|---|---|
74036 | 2017-7-5 | A WebBrowser component in Nexacro Browser adopts the IWebBrowser2 control. According to the official response from the developer of this embedded interface (i.e. Microsoft), repeated creation and deletion of the control will increase the use of memory due to the control's nature. Therefore, you are recommended to reuse one WebBrowser continuously after creating it. |
onmouseout event of Div fails to occur if you move mouse pointer quickly
If the onmouseout event is set for a Div component that contains child components, onmouseout should occur when a mouse cursor moves through the Div. However, the event will not occur if the cursor moves quickly.
See the below example where the blue and red zones are a Div and Button component respectively. If you move a mouse pointer quickly from the bottom to the top of the Div through the Button, onmouseout may not occur occasionally.
The below HTML code represents the above example, while the code would be more complicated if it was generated with the Button actually placed. The failure to trigger onmouseout in a web browser happens only when a Div tag is nest within another Div tag.
<div id="mainframe_VFrameSet0_ChildFrame0_form_Div00" style="left: 141px; top: 504px; width: 400px; height: 115px; background-color: rgb(0, 0, 255); "> <div style="position: absolute; left: 20px; top: 20px; width: 300px; height: 73px; background-color:red; ">Button00 </div> </div>
RP | Written in | Description |
---|---|---|
76382 | 2017-10-16 | This restriction occurs occasionally when you move a mouse pointer quickly. |
Restrictions related to WKWebView in iOS
As iOS adopts WKWebView, two restrictions have emerged in relation to cross-origin resource sharing, as described below.
Restriction on the use of a cookie
No cookie is permitted with the content file (Run.html) running in a local path (file://).
You cannot even access cookies through a script (document.cookie) or set cookies by using the WKWebView API (WKHTTPCookieStore).
Local files cannot be accessed through the url property of the WebBrowser.
Restriction is imposed on the components using iFrame with the content file (Run.html) running in a local path (file://).
You also cannot access an HTML file by using the callMethod method of the WebBrowser.
If you have to use cookies in iOS or call the callMethod method of the WebBrowser in iOS, you should follow the below procedure to call the Run.html file from the server.
1
Delete the update from the TypeDefinition.
Otherwise, delete the settings related to "resource"
in the start_ios.json file, which is created through the menu Archive of Nexacro Studio.
"resource" : { }
2
Modify Run.html as below.
Decompress the Run.zip file, which created through Archive of Nexacro Studio. Open the Run.html file with a text editor and then delete the lines intended to call the archivefiles.js file. Then, delete the project URL defined as an argument of the load function to make it as an empty value.
<script type="text/javascript" src="./archivefiles.js"></script>
>>
Deleted
application.load("TEST", "TEST.xadl.js", "http://localhost:8080"); >> application.load("TEST", "TEST.xadl.js", "");
Even if you enter an empty value as a project URL at the menu Archive, Nexacro Studio will set a default URL automatically when creating Run.html. Accordingly, you should modify Run.html itself.
3
Place the modified Run.html in the same location with start_ios.json.
Files produced as a result of generation, Run.html and start_ios.json should be in the same location of the same server.
4
Add the isDirect option to AppDelegate.m.
Add the isDirect option (isDirect=YES
) to the AppDelegate.m, one of the files set in the process of building the app.
@implementation AppDelegate -(NexacroMainViewController*)initMainViewController:(NSInteger)nView { [[NexacroResourceManager sharedResourceManager]setBootstrapURL: @"http://172.10.10.10:8080/nexacro/start_ios.json" isDirect=YES]; return [[AppViewController alloc] initWithLoader:nView]; } @end
RP | Written in | Description |
---|---|---|
- | 2019-12-24 | Since December 2019, the minimum required version of iOS has officially changed to 9. This restriction is attributable to the security policies applied to WKWebView in iOS. |
Two types of scrollbars appear simultaneously in TextArea
Nexacro Platform applies its own scrollbars instead of default scrollbars of HTML. To this end, the platform not only disables HTML default scrollbars but also hides them.
When iOS improved its scrolling functionality in the version 13, it changed some properties related to scrolling. With such change causing the appearance of HTML default scrollbars, which used to be made invisible, now the two types of scrollbars are displayed simultaneously.
There are bypasses that prevent the two types of scrollbars from appearing at the same time. Since such circumvention affects features and actions related to scrolling, however, we have decided to maintain the current state and declare this issue to be a restriction.
RP | Written in | Description |
---|---|---|
87651 | 2019-11-19 | This restriction occurs in iOS 13 or later. |
Long-pressing is treated as touching-and-moving
iOS does not allow developers to handle the events related to long-press gesture. Accordingly, Nexacro Platform does not tap into iOS' events. Instead, it measures by itself the amount of time when a user touches the screen to distinguish between a simple touch and long-press gesture.
In the versions earlier than iOS 13, long-pressing on a component with an editable field (Input DOM) led to a magnifying glass UI. In iOS 13, however, the same action causes a cursor to get bigger. In this process, Nexacro Platform has become unable to differentiate between a simple touch and long-press. This is because the minimum duration required to recognize a long-press gesture is too short in iOS 13.
Therefore, applications can behave against users' intentions in iOS 13 or later. For example, a step layout moves when the user actually intends to long-press because iOS treats it as a touch-and-move action.
RP | Written in | Description |
---|---|---|
87416 | 2019-11-20 | his restriction occurs because iOS fails to clearly open the events related to a long-press gesture. |
Long-pressing on Form with scrollbar makes screen shake
Assume that, in iOS 13 or later, you open a virtual keyboard by selecting a component with an editable field in a Form with a scrollbar. At this point, you will find the screen shake and then the caret disappear if you long-press the editable field.
This behavior is decided to be a restriction because it also occurs in an HTML page in the same conditions.
RP | Written in | Description |
---|---|---|
87425 | 2019-11-20 | This restriction occurs in iOS 13 or later. |
Component's value cannot be fetched within onclick before Japanese characters are fully combined
In iOS 13 or later, the process of combining characters cannot be completed by using a script when the input is in progress. The time when the combination is completed varies according to the versions of iOS.
iOS version | Sequence of events |
---|---|
Earlier than 13 | ontouchend > completion of combination > onclick |
13 or later | ontouchend > onclick > completion of combination |
In the versions earlier than 13, you can fetch the value of a component through the handler of the onclick event because the character combination is completed before onclick. In iOS 13 or later, however, the handler will return "undefined" as the value.
If you use iOS 13 or later and need to check characters being combined through onclick, you should use the text property.
An error may occur if you change a component's value or a caret's position before the process of combining characters is completed. Therefore, you are recommended to make such a change within the onchar event after the combination is completed.
RP | Written in | Description |
---|---|---|
88242 | 2020-01-13 | This restriction occurs in iOS 13 or later. |
Difference between Browsers
Difference in displaying cursor in editable field
If a component with an editable field has the readonly property set to "true", a cursor will be displayed in the field differently according to browsers. The value of readonly will be applied regardless of how to display a cursor, and you cannot edit the text in the editable field.
Browsers | How to display cursor |
---|---|
Firefox, IE | A cursor is displayed in an editable field, plus you can change the position of the cursor by clicking a mouse. |
[Runtime], Chrome, Edge, Safari | A cursor is not displayed. |
RP | Written in | Description |
---|---|---|
37637 | 2014-09-24 | This is a problem caused by the difference between browsers. |
Restriction on style-related properties
The below table is a list of style-related properties that are not supported by Nexacro Platform or are supported in some browsers only.
Property | Support | Remark |
---|---|---|
blur | No | Not supported because behavior and compatibility vary according to browsers |
glow | No | Not supported because behavior and compatibility vary according to browsers |
shadow | Not in IE8 | |
gradation > radial | No | |
gradation > peglist | Not in IE8,9 | |
opacity | Not in IE8 | |
background > imageedge | This property can work improperly depending on its input value. If it works improperly, the background image will be displayed differently according to browsers. | |
cursor | Not in Firefox, [Runtime] | This property provides a function to switch the type of a cursor if there is a change in the element over which the cursor hovers. The change in the element was caused by a change in another property while the cursor does not move. However, the aforementioned function may not be performed properly. |
RP | Written in | Description |
---|---|---|
40056 | 2015-02-26 | background > imageedge |
40862 | 2015-03-24 | gradation > radial |
68620 | 2016-08-25 | blur |
68510 | 2016-09-29 | shadow |
Difference in aligning text in Grid cell
With the halign property set to "center", the alignment of the text in a Grid cell will be different between the Runtime browser and web browsers.
RP | Written in | Description |
---|---|---|
47603 | 2016-03-30 | With the halign property set to “center”, a Grid cell will center its text based on the text area rather than on its size. This problem occurs when the white-space property is set to “pre” in the HTML document. Meanwhile, the Runtime browser is internally equipped with an alignment function, which produces a different result. |
Restriction on hotkey property
The hotkey property can work differently according to browsers if you specify the property with a value that is the same as one of the keyboard shortcuts defined by web browsers.
RP | Written in | Description |
---|---|---|
48488 | 2016-07-05 | This problem is caused by the difference between browsers. Therefore, we recommend you not to specify hotkey with a value that is the same as one of the keyboard shortcuts defined by web browsers. |
Difference in presenting file paths in FileUpload
With the multiselect property set to "true", a FileUpload component will present file paths differently according to browsers.
Browsers | How to present file paths |
---|---|
[Runtime] | File path + file name |
Chrome, Edge, Firefox, IE, Safari | file name |
With the multiselect property set to "false", a FileUpload component will present file paths differently according to browsers.
Browsers | How to present file paths |
---|---|
[Runtime] | File path + file name |
Chrome, Edge, Firefox, IE, Safari | Fake path + file name |
With multiselect set to "false", a FileUpload running in IE can present an actual file path rather than a fake path depending on the Internet Options set by IE users.
RP | Written in | Description |
---|---|---|
69218 | 2016-09-06 | This problem is caused by the difference between browsers. File uploading will be conducted successfully although the methods of presenting file paths are different across browsers |
81686 | 2018-09-05 | The explanation—about displaying a file path when the multiselect property is set to "false"—has been modified. A fake path rather than an actual file path is displayed in Microsoft Edge or Internet Explorer. |
Difference in processing repeated child frame names produced by open method
A script error will occur in Internet Explorer and thus a pop-up will fail to appear when you call the open method of an application object multiple times. This error occurs when you specify all the strName parameters with the same value. The parameter is designed to define the name of a child frame opened by the method.
While a script error will not occur in the Runtime browser and other web browsers under the same condition, this problem is caused by the difference between browsers in processing pop-ups.
Browser | Transaction type | How to process pop-ups |
---|---|---|
[Runtime] | Synchronous | It processes pop-ups consecutively. |
Chrome | Asynchronous | It processes only the JavaScript codes written for the last pop-up. |
Firefox | Asynchronous | It processes only the JavaScript codes written for the first pop-up. |
IE | Asynchronous | It processes all JavaScript codes for opening pop-ups, which in turn causes a script error. |
When a pop-up is opened, the ID of the child frame can be processed differently between browsers and even versions within the same browser. Therefore, we advise you not to specify the same ID for multiple frames.
RP | Written in | Description |
---|---|---|
70213 | 2016-12-05 | This problem is caused by the difference between browsers. |
Difference in processing alert or confirm method that is included in a function
Google Chrome processes the alert or confirm method earlier than any other codes when those method are included in a function.
For instance, the below sample codes are intended to print the string "TEST" first and then execute the alert method. However, Google Chrome will call alert first and will not print "TEST" until you close the alert window.
function fn_click() { document.write("TEST"); alert("TEST"); }
RP | Written in | Description |
---|---|---|
71291 | 2017-01-09 | This problem is caused by the difference between browsers. |
Slow application of visible property
When you change the value of the visible property of a component through a script, subsequent codes may be executed before the status of the component displayed on the screen changes. This problem occurs often in IEs running in low-performance PCs.
RP | Written in | Description |
---|---|---|
71551 | 2017-01-31 | When you change the value of visible, the change will be applied to the DOM object in the relevant HTML document. The rate of such process may vary according to devices and browsers Therefore, you should design the statements in your script to be processed consecutively. Otherwise, you can fine-tune the timing of applying the change by using a timer event. |
Sequence of onmouseenter and onmousemove events
If a component has both the onmouseenter and the onmousemove events, the sequence of the events varies depending on browsers. The below table presents the sequences according to browsers.
Browsers | Sequences |
---|---|
IE, Edge | onmousemove > onmouseenter |
[Runtime], Chrome, Firefox, Safari, Opera | onmouseenter > onmousemove |
RP | Written in | Description |
---|---|---|
71731 | 2017-02-10 | This problem is caused by the difference between browsers. |
Base for executing trackPopup method
The base for opening a component (PopupDiv or PopupMenu) can vary when calling the trackPopup method. In the Runtime environment, the frame area including a titlebar serves as the base while the contents area excluding a title bar serves as the base in the HTML5 environment. Therefore, the position of opening a component can vary even when the same coordinate values are specified with the showtitlebar property set to "true".
Alternative scripts | You should not manipulate the method in order to remove the difference because such manipulation can cause the failure to execute the script of the application. There are two alternatives; one is the use of the trackPopupByComponent method. The other is the removal of the frame area in the Runtime browser when calculating the position of opening a component. |
---|
// Using the trackPopupByComponent method var x = this.Button00.getOffsetLeft(); var y = this.Button00.getOffsetBottom(); this.pdiv.trackPopupByComponent(this, x, y);
// Removing the value of the frame area in the Runtime browser var objBut = this.Button00; // Button serving as the base for opening the component var v_nX = system.clientToScreenX(objBut, 0) - system.clientToScreenX(application.mainframe, 0); var v_nY = system.clientToScreenY(objBut, parseInt(objBut.height)) - system.clientToScreenY(application.mainframe, 0); var v_sRet = this.pdiv.trackPopup (v_nX, v_nY);
RP | Written in | Description |
---|---|---|
71863 | 2017-03-14 | This problem is caused by the difference between the Runtime browser and web browsers. |
Difference in results of executing nexacro.getTextSize
The getTextSize method is used to calculate text size by factoring into its parameters. However, calculation results may vary according to browsers.
Calculation results can vary according to browsers as well as the arguments of the parameters. The below table shows the difference in results when the method is executed with certain arguments in different browsers. The below table is presented just to help your understanding.
this.Static00.set_text("nexacro"); this.Static00.style.set_font("10 Arial"); var textSize = nexacro.getTextSize(this.Static00.text, this.Static00.style.font, null, "none", 0); trace(textSize.nx, textSize.ny); // Results
Browsers | Results |
---|---|
IE11 | 47, 15 |
Edge | 47.41999816894531,15 |
[Runtime], Safari | 46, 16 |
Firefox | 46, 15 |
Chrome | 47.42295837402344, 15 |
RP | Written in | Description |
---|---|---|
72660 | 2017-6-20 | This is a problem caused by the difference between browsers. |
Geolocation is replaced by browsers' own objects
Some browsers employ their own objects instead of a Geolocation, an object from the DeviceAPI object of Nexacro Platform. This problem occurs when you specify the ID of the object as "Geolocation" in the TypeDefinition.
This problem occurs because IE and Microsoft Edge have their own objects named "Geolocation". Therefore, your application will work properly if you change the ID of the object to something different like "NexacroGeolocation".
RP | Written in | Description |
---|---|---|
75116 | 2017-8-2 | This is a problem caused by the difference between browsers. Particularly, this bug is caused by the use of IE or Microsoft Edge. |
Restriction caused by transaction method executed in synchronous mode
You can set the synchronous mode for transmitting data by setting the bAsync parameter of the transaction method to "false". In this case, however, your application may not work properly in some browsers.
Browsers | Bugs |
---|---|
Chrome, Firefox | A message will appear, indicating that the request is deprecated. |
IE, Edge | Focus will be lost after the calling of the transaction method. |
RP | Written in | Description |
---|---|---|
74564 | 2017-7-25 | This is a problem caused by the difference between browsers. Some browsers are treating the synchronous data transmission mode as deprecated due to its negative effect. Further restrictions can be imposed in the future as browsers update their versions. |
Text Entered in Edit Blinks
Text entered in an Edit component can appear blinking or moving if you enter the text, move the focus out from the Edit and bring the focus back to the component.
RP | Written in | Description |
---|---|---|
75016 | 2017-7-27 | This is a problem caused by the difference between browsers. This bug occurs in IE running in Windows 7. |
Text in Grid is Hidden Partially in Zoomed-in Browser Page
Text in a Grid cell is hidden partially when the browser page zoomed in. This error occurs when the align property of the cell is set to "right".
RP | Written in | Description |
---|---|---|
75097 | 2017-8-7 | This is a problem caused by the difference between browsers. This bug occurs in IE and Microsoft Edge. This bug does not occur sometimes even under the same conditions according to the values of the font property. |
Restriction on Calling of setPrivateProfile or getPrivateProfile Method in Safari
A script error will occur if you call the setPrivateProfile or getPrivateProfile method of an Application object when you use Safari. The error will occur in the below-mentioned case and is attributable to Apple's policies for Safari.
When Private Browsing is turned on
RP | Written in | Description |
---|---|---|
43492 42186 | 2015-6-25 | You cannot use the localStorage function if you set a specific option when you use Safari. By contrast, you can use the setPrivateProfile or getPrivateProfile method if you do not set that option. This restriction applies to Safari running in the iOS, Windows, or macOS environment. |
Caret in Edit Penetrates Another Component
This error occurs when another component hovers over an Edit component. If you move focus to the under-lying Edit, a caret in the Edit will appear penetrating the hovering component.
RP | Written in | Description |
---|---|---|
75777 | 2017-9-5 | This incident occurs in Microsoft Edge and IE when the browsers process the <input> tag surrounded by the <div> tag. |
IE fails to process pending events while it is taken up for a certain amount of time by a specific script
IE fails to process pending events while it is taken up for a certain amount of time by a script that conducts the sleep method of a Form or performs a repetitive statement like a for-loop.
Let us assume that you trigger an event by clicking a Button component while sleep is being executed in IE. In addition, assume that you have designed the script to process the Button-triggered event after the span specified by the parameter of sleep. However, you will find IE failing to process the event.
RP | Written in | Description |
---|---|---|
75144 | 2017-8-18 | This is a restriction created by Internet Explorer. When codes are blocked by IE, events will be deleted with the body part losing focus. |
Different behavior between browsers when the 'undo' item is selected from a context menu
Browsers show different behavior in response to the 'undo' command. This restriction is faced under the following condition. To begin, select text in an editable component, right-click to open a context menu and choose 'Delete' or 'Cut'. Then, move the focus to another component, open a context menu and choose 'Undo'. This is the point when the restriction has an effect.
Browser | Result |
---|---|
Chrome, IE11 | The deleted or cut value will be restored. |
Firefox | The context menu opened from the latter component has an inactive 'Undo' item, so you cannot select it. |
[Runtime], Edge, Safari | The context menu opened from the latter component has no 'Undo' item, so you cannot select it. Moreover, you cannot apply the 'undo' shortcut. |
When you use the <input> tag of HTML, executing the 'undo' command yields partially different results compared to a Nexacro Platform-based application. The reason for this difference is that some browsers cannot deliver the event triggered by the 'undo' command.
Browser | Result (Only <input> tag is used in HTML document) |
---|---|
Chrome, IE11 | The deleted or cut value will be restored with focus going back to the previous component. |
Firefox | The context menu opened from the latter component has an inactive 'Undo' item, so you cannot select it. |
Edge, Safari | The context menu opened from the latter component has no 'Undo' item. However, the deleted or cut value will be restored with focus going back to the previous component when you enter the Ctrl+Z shortcut. |
[Runtime] | The context menu opened from the latter component has no 'Undo' item, so you cannot select it. Moreover, you cannot apply the 'undo' shortcut. |
RP | Written in | Description |
---|---|---|
75871 | 2017-10-10 | This is a restriction caused by the difference between browsers. |
Restriction on calling of alert and confirm methods within onbeforeexit event
Some browsers may fail to call the alert and confirm methods if they are written within the handler of the onbeforeexit event of an Application object. Browsers should call those methods indeed unless they are written within the handler of the onbeforeexit event.
Browser | Result |
---|---|
Chrome, Edge, Firefox, | Those methods are ignored within the handler of the onbeforeexit event. |
[Runtime], IE, Safari | Those methods are called within the handler of the onbeforeexit event. |
The onbeforeexit event is designed to bring in the beforeunload event of HTML.
The HTML5 specification states that calls to the alert and confirm methods may be ignored during the beforeunload. And behavioral difference exists because each browser processes this event differently.
https://developer.mozilla.org/en-US/docs/Web/Events/beforeunload
RP | Written in | Description |
---|---|---|
76480 | 2017-10-10 | This is a restriction caused by the difference between browsers. |
Failure to display displaynulltext property's value with enable property set to false
With the displaynulltext property set, the component will display the property's value if the component is not focused and has 'null' as a value. However, the behavior of the component varies according to browsers; particularly, when the enable property of the component is set to 'false' through the script while the component has focus. In some browsers in that case, the component cannot display the value of displaynulltext although the focus will move to the next component.
The blur event is fired by browsers under the following two conditions: first, a component loses focus due to the change in the value of the enable property. Second, the change is caused by the script rather than by pressing the tab key or clicking outside the component. The value of displaynulltext can be displayed as Nexacro Platform processes blur. However, some browsers do not trigger blur, thus failing to display the value of displaynulltext.
Browser | Result |
---|---|
Edge, IE, Firefox, | These browsers do not trigger the blur event caused by the change in the value of the enable property. Therefore, the relevant component cannot display the value of the displaynulltext property although the focus moves to another component. |
[Runtime], Chrome | These browsers trigger the blur event caused by the change in the value of the enable property. Therefore, the relevant component displays the value of the displaynulltext property when the focus moves to another component. |
RP | Written in | Description |
---|---|---|
76456 | 2017-10-10 | This is a restriction caused by the difference between browsers. |
Focus fails to move to editable component when you make touch actions quickly
This restriction is caused by the Safari browser running in the iOS environment when there is an editable component like an Edit. If you touch another component and then an editable component quickly, the editable component will not become focused while the 'focused' pseudo-class will apply to the component.
This is a browser-specific restriction. Nexacro Platform changes the pseudo-class of the editable component when a touch event occurs in Safari. However, Safari fails to move the focus although the browser has triggered the touch event. Accordingly, Nexacro Platform cannot correct this problem since Safari successfully delivers the event to Nexacro although it fails to move the focus.
RP | Written in | Description |
---|---|---|
77192 | 2017-11-27 | This restriction occurs in Safari running in the iOS environment. The change in a pseudo-class is legitimate because it results from the process of handling an event from a browser. Therefore, this problem will be resolved automatically when the browser removes this restriction. |
Div blinks when focus moves to an editable child component that is partially hidden
This restriction is caused by Internet Explorer (IE) when a Div component contains an editable component that is partially hidden. If focus moves to the editable component, IE is designed to scroll the Div so that the editable component shows entirely. In this case, however, Nexacro Platform is designed to scroll the Div back to the original position because the previous scrolling was not intended by a user. Going through the whole process, the entire Div may appear to blink.
Normally, components inside a Div will not be hidden upon the screen loading. However, the components can be hidden when you resize the Div, and this is when the blinking of the Div can occur.
RP | Written in | Description |
---|---|---|
76992 | 2017-11-28 | This restriction occurs in IE8 to 11. |
Caret moves unintentionally if focus moves to editable component when wait cursor shows
In the editable field of a component, you can see a caret moving to the end of the field rather than showing in the position that you click. This problem occurs as the following two actions happen at the very same time: one is moving focus to the component by clicking and the other is calling transaction or setWaitCursor method.
This restriction applies only to Internet Explorer (IE). The cause is that a layer for a wait cursor is activated, and the layer overlaps the editable field of a component. This restriction occurs when an <input> tag is nested within a <div> tag.
RP | Written in | Description |
---|---|---|
77440 | 2017-12-14 | This restriction is caused by the difference between browsers. It occurs in IE. |
Only caret moves without focus if you drag and drop mouse pointer between components
There is a restriction where a caret moves from an editable component to another editable component while the focus does not. This problem occurs when you press the right button of your mouse in the beginning component, move the mouse pointer to the other component with the button still pressed and then release the button.
RP | Written in | Description |
---|---|---|
77433 | 2017-12-27 | This restriction is caused by the difference between browsers. It occurs in Internet Explorer. |
Event bubbling when enable property is set to 'false'
As for editable components, rules of event bubbling (to a Div or Form) are different according to web browsers. This restriction is imposed when you click the editable fields with the enable properties of those components set to 'false'.
Browsers | Event bubbles or not |
---|---|
Firefox, Edge | An event does not bubble to parent components. |
[Runtime], Chrome, IE, Safari | An event bubbles to parent components. |
You can test this restriction with the below HTML code. If you click the inputtable field of the component at the lowest level, the onmousedown event within the <div> tag will be fired in the browsers that bubble the event. In Firefox and Microsoft Edge, however, the event will not be fired.
<div onmousedown="console.log('div onmousedown')"> <input type="text" disabled> <input type="text"> </div>
This restriction applies only to an editable field. For example, a click-related event will not bubble if you click the editable field of a Calendar. Meanwhile, the same event will bubble if you click the button or DatePicker control of the Calendar.
RP | Written in | Description |
---|---|---|
77734 | 2018-01-16 | This restriction is caused by the difference between browsers. |
Style defined for mouseover remains after mouse cursor moves out
This restriction is related to Safari running in macOS and to a style defining the background color of the mouseover pseudo-class. When you hover a mouse cursor over the relevant object, the defined background color will be applied. However, the color will remain even after the mouse pointer leaves the object.
This restriction is caused by the characteristics of Safari and found in other web applications.
https://bugs.webkit.org/show_bug.cgi?id=4117
RP | Written in | Description |
---|---|---|
81852 82067 | 2018-10-16 | This restriction involves Safari running in macOS. |
Caret appears at the beginning of next line in TextArea when clicking empty space at the end of text on certain line
This restriction involves a TextArea containing multiple lines of text with line feed characters. If you click the empty space that trails behind a certain line of text, a caret may be placed at the beginning of the next line instead of the end of the text on the relevant line. This behavior is mostly found in IE8 and sometimes in IE9, IE10 and IE11.
If you click the space 1 in the above picture, a caret should appear at 2, which is the end of the text on the third line. In IE browsers, however, a caret will sometime appear at 3, which is the beginning of the fourth line.
RP | Written in | Description |
---|---|---|
82352 | 2018-10-24 | This restriction applies to IE browsers. |
Varying sequence between onkeydown, onkeyup and ontextchanged events
As seen in the below table, the sequence of events varies according to browsers when you enter Korean characters in an Edit. If the onkeyup event includes a script to check a Korean language input and the event occurs in Microsoft Edge, the script may not work properly.
Browsers | Sequence of events |
---|---|
Edge | onkeydown > onkeyup > ontextchanged |
[Runtime], IE, Chrome, Firefox, Safari | onkeydown > ontextchanged > onkeyup |
RP | Written in | Description |
---|---|---|
82252 | 2018-10-15 | This restriction is caused by the difference between browsers. |
Contents are reloaded when Z-order of WebBrowser changes
You can change the stack order of a WebBrowser by calling the bringToFront or sendToBack method. In this case, the contents loaded on to the component will be reloaded. When a WebBrowser operates in a web browser, the component will be converted into an iframe tag. The web contents defined by the url property will be reloaded if the order of the iframe tag changes or the iframe’s parent node changes. This behavior is a basic design of web browsers.
If a WebBrowser is placed within a Div, the web contents of the WebBrowser will be reloaded if the bringToFront or sendToBack method of the Div is called.
The relevant issue is registered in the request list, and we answer that we cannot accommodate the request.
We may accept such a request in the future provided that certain web browser are updated as appropriate.
Moving an IFRAME within the DOM tree results in reloading of content
https://bugs.webkit.org/show_bug.cgi?id=13574
In the Runtime environment, Z-order can change without reloading contents. However, you should be mindful of this restriction when you develop an application that supports both the Runtime and HTML5 environments.
RP | Written in | Description |
---|---|---|
73441 | 2017-05-19 | We answered that this behavior is inevitable because it is a basic design of web browsers. |
82799 | 2018-11-14 | In response to the request, we defined this issue as a restriction. |
Clicking Cancel button in file dialog of FileUpload leads to different behaviors
Assume that you open a file dialog by clicking the Find button of a FileUpload component and then select a file. Next, you click the Find button again and then click the Cancel button to close the dialog without selecting any file. Eventually, you will find that the previously-selected file has been removed from the FileUpload after closing the file dialog.
Because clicking the Cancel button calls off the previously-selected file, the relevant item will be removed from the filelist property, followed by the occurrence of the onitemchanged event. This incident can occur only in Google Chrome.
-- the onitemchanged event occurs when you select a file onitemchanged / this.FileUpload00.filelist[e.index]: [object VirtualFile] onitemchanged / e.newvalue: C:\fakepath\a.png onitemchanged / e.oldvalue: -- the onitemchanged event occurs when you click the Cancel button without selecting a file. onitemchanged / this.FileUpload00.filelist[e.index]: undefined onitemchanged / e.newvalue: onitemchanged / e.oldvalue: C:\fakepath\a.png
Browser | Behavior |
---|---|
Chrome | Clicking the Cancel button removes the information on previously-selected files. Clicking the Cancel button fires the onitemchanged event. |
[Runtime], IE, Edge, Firefox, Safari | Clicking the Cancel button leads to nothing. |
This issue has been reported to Google, who provided an answer that this is a feature of the browser.
https://bugs.chromium.org/p/chromium/issues/detail?id=2508
You can also find this behavior when you use a file input (the <input type="file"> tag) in Google Chrome.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/file
RP | Written in | Description |
---|---|---|
84900 | 2019-04-23 | This is a problem caused by the difference between browsers. |
Restrictions Inherent in Nexacro Platform
Form's background color fails to apply when the Form is connected to Div
Styles defined in a CSS file will not apply to a form if the form is specified as the value of the url property of a Div component.
For example, place two Div components in a Form (a.xfdl) and specify b.xfdl and c.xfdl as the values of each Div. As you apply the same background color to both Div components, specify the test.css file as the style of b.xfdl while specifying the background property of c.xfdl. As the result, only c.xfdl presents the background color while b.xfdl does not.
The background color will be presented successfully if b.xfdl is executed without being linked to a Div component.
RP | Written in | Description |
---|---|---|
44258 | 2015-10-19 | If a Form is specified as the value of the url property of a Div component, Nexacro Platform will treat the Form as a Div. In such a case where the type of a component changes, the style-related properties defined in an existing CSS file will not apply to the component any more. |
Restriction on popuptype property of Calendar
There will be change in the range of supported events if the popuptype property of a Calendar component is set to "system" in mobile devices. The supported/unsupported events are listed below.
Events | |
---|---|
Supported | onlbuttondown, onlbuttonup, oneditclick, onmouseenter, onmousemove, ondrag, onsetfocus, onkillfocus, onsize, onmove, ontouchstart, ontouchmove, ontouchend, onmouseenter, onmousemove, onlongpress, onpinchstart, onpinch, onpinchend, ontextchange, cancharchange, onchar, ontextchanged |
Unsupported | onchanged, ondayclick |
RP | Written in | Description |
---|---|---|
47974 | 2016-05-13 | Some events cannot be supported depending on the value of the popuptype property of a Calendar component. |
Color fails to be copied from cell in Excel file exported from ExcelExportObject
If you copy a cell in an exported Excel file and paste it into a new Excel document, the color defined in the copied cell will not be copied. This problem occurs with the exporttype property of the ExcelExportObject set to nexacro.ExportTypes.EXCEL
when the Excel file was exported.
RP | Written in | Description |
---|---|---|
48114 | 2016-05-18 | From Excel 97 through 2003, a user-defined color only can apply to the relevant file. Therefore, when you copy a cell and paste it into a different file along with a user color, the cell will be presented in a different color because the information on the user color will not be found. |
Difference in mask property between MaskEdit and Grid
The mask property can apply to both a MaskEdit component and a Grid cell object. While most features are the same, some are different between the two objects.
Component | Value of type/displaytype property | How to process masks |
---|---|---|
MaskEdit | type:number | #: all the digits (0-9) 9: all the digits (0-9) |
Grid > Cell | displaytype:number | #: all the digits (0-9) (no output if the input is 0 or none) 0: all the digits (0-9) (0 will be printed if the input is none.) |
RP | Written in | Description |
---|---|---|
69322 | 2016-09-13 | The difference remains for backward compatibility. Accordingly, we advise you to use the mask property with the difference in mind. |
Restriction on event bubbling from editable components
Events that occur in editable components does not bubble to the HTML documents unlike other types of components.
Events that occur in editable components are not delivered outward from a WebBrowser component if a Nexacro Platform-based application is the value of the url property of the WebBrowser. This is also true when the application comes within IFrame tags in an HTML document.
RP | Written in | Description |
---|---|---|
48534 | 2016-12-22 | Events that occur in an Input DOM node will be processed within the input element while the calling of the stopPropagation method will prevent those events from bubbling to the HTML document. |
Restriction on selecting multiple cells in Grid after zooming in/out
Selection of multiple Grid cells will function differently from your intention when you drag-select those cells after you have zoomed in or out on the web page. This problem occurs when the selecttype property of the Grid is set to “multiarea”. The function of selecting multiple cells uses screen coordinate values because cells should be selected even if the mouse pointer leaves the Grid area in the process of selection. This mechanism causes the malfunction.
Browser | Conditions for restriction |
---|---|
[Runtime] | When setting the showzoomcombo property to "true" and using the zoom in/out features |
Web browsers | When using the zoom in/out features of web browsers |
RP | Written in | Description |
---|---|---|
70879 | 2017-01-17 | The below causes are the reasons for the selection of unintended cells. 1) The component will be resized on the screen after zooming in or out, but its size will not change in the HTML node. 2) As the component is resized on the screen, the area selected by the mouse pointer will change. |
Restriction on align property of TextArea
As for the align property of a TextArea component, Nexacro Platform only supports the "top" value for the vertical alignment. It supports only the "left" value for the horizontal alignment when a horizontal scrollbar is activated. The below property settings are the conditions for activating a horizontal scrollbar, which is also affected by the length of input text.
wordwrap: none scrollbars: autoboth, alwayshorz, fixedboth, fixedhorz, autohorz
RP | Written in | Description |
---|---|---|
71468 | 2017-01-18 | This restriction has an effect on the Runtime environment as well as on web browsers. You cannot use the property's values other than "top" and "left". |
Styles for Grid's control button are not defined in default.xtheme
Styles for a Grid's control button are not defined in default.xtheme file, which is provided from the installation of Nexacro Studio.
RP | Written in | Description |
---|---|---|
71548 | 2017-01-24 | Those styles have not been defined in default.xtheme since the inception of the product. It would be inappropriate to correct default.xtheme now because many users already define their own styles for the control. |
Restriction on printing out WebBrowser
Normally, the System.print method prints out the whole area of a Form, including the hidden area to which you have to scroll to present the area on the screen. If a WebBrowser component is included in the Form, however, such a hidden area will not be printed out while only a currently-seen area will be printed. The reason is that, in that case, calling the System.print method will lead to the execution of the window.print method of JavaScript.
Browser | How to process the System.print method |
---|---|
[Runtime] | Prints out the whole area of a Form regardless of a WebBrowser included in the Form |
Chrome, Edge, Firefox, IE, Safari | Prints out the only currently-seen area of a Form when a WebBrowser included in the Form |
In the below sample, two Edit components are placed on the upper and lower sides of a Form while a WebBrowser component is placed on the right-hand side, showing a map. If the System.print method is called in the Runtime environment, the area of a red rectangle will be printed out. By contrast, the area of a blue rectangle will be printed out in web browsers as the area is currently seen on the screen.
RP | Written in | Description |
---|---|---|
71680 | 2017-02-08 | The way of processing the system.print method is different between the Runtime and web browser environments due to web browser-related restriction. |
Difference between Nexacro Platform and JavaScript methods
If you call the alert or confirm method without specifying a selector, the relevant methods from JavaScript will be executed. Those JavaScript methods may function differently to those from Nexacro Platform.
this.Button00_onclick = function(obj:Button, e:nexacro.ClickEventInfo) { alert("TEST"); // javascript alert method this.alert("TEST"); // Form object alert method application.alert("TEST"); // Application object alert method }
As seen in the below picture, methods redefined in Nexacro Platform include codes for performing the platform's unique algorithms. Therefore, those will be processed in a way different to basic JavaScript methods.
RP | Written in | Description |
---|---|---|
2017-05-22 | This restriction occurs because some methods of Nexacro Platform share the same names as their counterparts in JavaScript. Accordingly, we recommend you to specify the selector Form or Application in your codes. |
Restriction caused by HTTP Header
If you set HTTP headers on the server side or use meta tags in HTML documents, some features of your application can be restricted according to security policies. The natures of the product account for such restrictions.
Content-Security-Policy
If you apply this policy, your application may not work depending on the settings of directives. Nexacro Platform libraries include codes containing eval
functions and in-line scripts. Such codes can conflict with the policy.
Therefore, you should add directives that grant permission for eval
functions and in-line scripts, as presented below.
<meta http-equiv="Content-Security-Policy" content="default-src *; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' 'unsafe-eval'">
X-Frame-Options
If the value of this header is set to "DENY", some features of your application may not work properly. Particularly, the "DENY" value forbids a WebBrowser component as well as image processing and text size caching features, which all use an iframe as a result of generating the application.
This problem can be solved if you do not apply the "DENY" value, as presented below.
<meta http-equiv="X-Frame-Options" content="… " />
RP | Written in | Description |
---|---|---|
72928 | 2017-6-15 | HTTP header-related restrictions can be evaded by adding directives or by avoiding using the relevant value. |
The following HTTP headers do not induce any restriction: X-Content-Type-Options, X-XSS-Protection and Strict-Transport-Security.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security
To prevent cross-site scripting (XSS), you should control the text entered in the page or let the server verify the input and then receive it.
It is hard for Nexacro Platform to overcome all types of security vulnerability. Basically, the platform considers data to be safe if it is transmitted from the server. Therefore, it is important for the server to produce reliable data.
Restriction on character length when receiving value from WebBrowser within onusernotify event
The onusernotify event is used to fetch a value from a web document loaded onto a WebBrowser component. In the Runtime environment, however, the delivered value has limits in the length of characters.
The Runtime version can process up to 512 characters maximum (256 characters in Korean and Japanese).
RP | Written in | Description |
---|---|---|
76512 | 2017-10-19 | The Runtime version is designed to receive a value through the window.document.title property of Internet Explorer, which has its limits in character length. |
Virtual keyboard covers editable component when Fullscreen is set in Android
Setting Fullscreen in the AndroidManifest.xml file as presented below may cause a restriction: when you move focus to an editable component, a virtual keyboard can cover the component so that you cannot make an input.
android:theme="@android:style/Theme.NoTitleBar.Fullscreen"
RP | Written in | Description |
---|---|---|
77480 | 2017-12-13 | FullScreen is not supported by a Nexacro Platform-based application running in the Android environment. |
WebBrowser is display on top in Android
You cannot place another component above a WebBrowser component in the Android Runtime environment. Even a pop-up component will be placed under a WebBrowser if the two component overlap.
RP | Written in | Description |
---|---|---|
78897 | 2018-03-15 | This restriction is applied when you execute an application that contains a WebBrowser component in the Android environment. |
Alert messages appear when application run on web browser
You will see the below alert messages if you run an application on Internet Explorer, open the developer tools and select the Console tab.
The above messages are caused by the faults in the conditional comments in the HTML files that are created as the result of generation. Since those are just alert messages, they will not pose any problem with the execution of an application. The reason for not fixing this syntax error is that such an attempt to change the conditional comments may have an impact on applications in operation.
(X) <!--[if gt IE 8]><!DOCTYPE html><!--<![endif]--> (O) <!--[if gt IE 8]><!--><!DOCTYPE html><!--<![endif]-->
RP | Written in | Description |
---|---|---|
81813 | 2018-09-19 | The above error is supposed to be fixed. However, it is decided not to fix the error because such an attempt may have an impact on applications in operation. |
Text can be selected by mouse actions even when the cell is not editable
The text in the Grid cells in the head and summary bands should not be selected with double-clicking or dragging because those cells do not have a control and thus cannot switch to the editable mode. The same will apply to the body band if the edittype property of the band is set to "none" and thus the relevant cells cannot switch to the editable mode.
When the editdisplay properties of cells are set to "display", moreover, the text should be unselectable regardless of edittype and bands since the relevant controls are not editable.
Even if a cell is not editable, however, text in the cell can be selected by mouse actions when the cell has the below-mentioned property values. Meanwhile, some users hope to keep this malfunctioning state since they are using it as it is. Therefore, it has been decided to maintain this bug.
- Head Band Cell editdisplay=display - Body Band Cell editdisplay=display
RP | Written in | Description |
---|---|---|
86141 | 2019-07-15 | Although this is a bug, it has been decided to maintain it because fixing the bug may affect the operation of the applications that use the malfunction. |
Nexacro Studio makes it seem that cell’s style can be set through CSS file although such functionality is not developed yet
You cannot style a Grid cell by using a CSS file since such a functionality is not developed yet. Even if you write a CSS file as shown below, the style set in the CSS file will not be applied.
Cell { padding : 3 3 3 3; }
If you check the Grid Contents Editor after setting the above CSS code, however, the editor makes it seem that the cell style set in the CSS file has been applied. However, the foregoing style does not take any effect actually.
This anomaly—a functionality seems to apply to Nexacro Studio even if it is not developed yet—is a bug. However, it has been decided to maintain this bug since fixing the bug may affect other functionalities.
RP | Written in | Description |
---|---|---|
73784 | 2019-05-27 | Although this is a bug, it has been decided to maintain it because fixing the bug may affect other functionalities. |
Restrictions on Right-to-Left (RTL) Feature
Caret's position in editable field when RTL is set
A caret is placed at the beginning of input text in an editable field when the text is English letters or numbers. This problem occurs in Google Chrome when the RTL feature is set.
RP | Written in | Description |
---|---|---|
68653 | 2016-09-05 | This is a problem that Google Chrome is responsible for. Although you can manually adjust the caret's position, we advise you not to do so because such an adjustment can affect other parts of the application. |
Return value of getCaretPos method when RTL is set
In Google Chrome, the return value of the getCaretPos method differs from those produced in other browsers when the RTL feature is set. This problem occurs when a string is entered in an editable field in order from Arabic letters, English letters to numbers. Moreover, the caret is placed somewhere in the middle of the string.
With the RTL feature set, the return value of the getCaretPos can vary according to browsers and their versions.
RP | Written in | Description |
---|---|---|
48750 | 2016-09-07 | This is a problem that Google Chrome is responsible for. |
Restriction on application of RTL to WebBrowser
The contents in a WebBrowser component is not affected by the RTL feature.
RP | Written in | Description |
---|---|---|
68436 | 2016-09-29 | A WebBrowser component uses IFrame tags internally. Nexacro Platform does not apply the RTL feature to the contents within IFrame tags because it treats the contents as a separate document object from other contents in the parent document. This is also true for the scrollbars in the component. |
Direction of scrollbar and caret's movement when RTL is set
The positions of a scrollbar and caret vary according to browsers when the Home or End button on the keyboard is pressed in an editable field. This problem occurs when the RTL feature is set.
Browsers | Function correctly or incorrectly? | How to work |
---|---|---|
[Runtime] | Correctly | A scrollbar and caret move leftward and rightward when entering the Home and End keys respectively. |
Chrome Safari | Incorrectly | A scrollbar and caret move rightward and leftward when entering the Home and End keys respectively. |
Edge | Incorrectly | A scrollbar and caret move leftward and rightward when entering the Home and End keys respectively. However, the End key malfunctions in a component for multiline input such as a TextArea. In such a component, entering the End key will move a caret to the next line when more than one line is inputted in the component. |
Firefox | Incorrectly | A scrollbar and caret move rightward when the Home button is entered. Meanwhile, the caret disappears and the scrollbar does not work when the End key is pressed. |
IE | Incorrectly | A scrollbar and caret move leftward for pressing either the Home key or the End key. |
RP | Written in | Description |
---|---|---|
69813 | 2016-10-20 | This is a problem caused by the difference between browsers. This problem occurs when the text in an editable field is written left to right only. |
Image is broken when RTL is set
Some images formatted in PNG will be broken in IE8 with the rtldirection property set to "rtl". This problem occurs in the process of changing the directions of the images.
We advise you to use IE9 or later, or to use other image formats like JPG, BMP and GIF.
RP | Written in | Description |
---|---|---|
70330 | 2016-11-04 | This is a restriction created by the rendering engine of IE8. |
Cancelled Restrictions
Restriction on synchronous communications
iOS Runtime environment supports only asynchronous communications rather than synchronous one.
RP | Written in | Description |
---|---|---|
42234 | 2015-05-12 | In an application for the iOS Runtime environment, binary/compressed data transactions can be conducted by using device APIs. Accordingly, synchronous communications are not allowed in the WebView environment, which is provided by iOS. |
2019-12-24 | Since December 2019, the minimum required version of iOS has officially changed to 9. As a result, the support for UIWebView has been stopped. Accordingly, this issue is no longer a restriction. |
Caret fails to show properly in iOS when editing text in web page loaded onto WebBrowser
A caret may not be displayed at an exact point where you touch the screen if the web page loaded onto a WebBrowser component uses the contenteditable attribute. This error occurs when you touch an editable text area.
This restriction occurs only in the iOS Runtime environment, which uses UIWebView. That is, this restriction occurs only when UIWebView is used.
If a caret is not displayed properly, close and re-open the virtual keyboard to make the caret displayed properly.
RP | Written in | Description |
---|---|---|
80635 | 2018-08-17 | A caret will not be displayed properly in an editable text area if the web page uses the contenteditable attribute. This problem occurs in the UIWebView environment provided by iOS. |
2019-12-24 | Since December 2019, the minimum required version of iOS has officially changed to 9. As a result, the support for UIWebView has been stopped. Accordingly, this issue is no longer a restriction. |