Posts by DecSoft

Hello John,

It's a bit frustrating, because this works like a charm in Firefox:

The point is that "chrome.browserAction.openPopup();" only works in what the documentation named "user action", like a context menu item click, for example. However, the above code don't work as expected in Chrome nor Edge, for example... :-(

However, there is also another possible approach. Take a look at the below code:

The above code can certainly show our app's desired view (note that we can avoid the local storage usage, that is, we can directly open the app's main view) as expected, that is, in another tab, and, that code works in Firefox, Chrome and Edge (and probably other modern browsers like Opera, etc.).

To my surprise, I try to place the "chrome.tabs.create" in a content script, for example, attaching a "dblclick" event to the body and try it, but, this don't work as expected: maybe because to use "chrome.tabs.create" we must use an "user action" like a context menu item click. I leave you as a task to try this (and search a bit around), if you don't want to use a context menu item. Maybe it's another way to create / open a new tab...

Another possible collateral issue can be the size of the popup. Suppose we have a WebExtension that at designtime is 300x300: we expect to have this size for the popup, but, when we open it (as above) in a new tab, the new tab size can be (probably it is) greater than 300x300. Here I propose to you a couple of possible solution: establish the app's MaxWidth and MaxHeight properties to 300 and 300, so the app openned in the new tab respect that size, because that's the maximum width and height.

The other possible solution can be to avoid the usage of AB controls, but use an HTML control, in which you can place the inputs (and other stuff) that you need: since these controls are not AB controlled (to say like that), they are not scaled. You must take a look in your own app, however, and see what of these options can be acceptable for your specific app case, John.

Since we can now open the app in a new tab, I am also thinking that maybe another possible approach is to open a window... a new window (with window.open) and then use the window.document.write() to prepare our HTML stuff: why? Because in this new window we don't have the "problem" related with the content pages, that is, this window do not have the styles, for example, of the content pages, so, maybe can be good for your purposes.

However, probably a new window can be a bit more tricky. I mention it because may you want to try it. I mean in order to control, for example, what the user type in the input controls... how to send that information to our app from the new window... maybe we don't share here the local storage, etc. Maybe this approach can be good, for example, if the new window present a form to the user to be submited to some app's server. Anyway, probably use an app's view... show one of our app's views in the new tab (as described above) can be the best... or better than the new window approach, at least if I am not wrong: I expect that, for example, some local storage saved in the app from the new tab, can be also available from the app shown in the popup...

Please, play a bit with the above code / **instructions**. I hope some of them can be useful for your specific app case, John.

Hello John,

I am not sure if we can go ahead with what you wanted... or it's a wrong approach. Please, let me to explain. The first in that I think is to use some lightbox Javascript library, and, certainly I can see someone that may can help: basiclightbox. This vanilla Javascript lightbox library consists on two files, one CSS and one JS, which we can add to our WebExtensions as content script and content style, respectively.

Additionally, we can add another content CSS file for our WebExtension with the below code:

Once we do the above, we can add this below Javascript code in our app's WebExtContent event, or, maybe in another Javascript file which we include as another content script for our WebExtension:

Note the usage of the "window.myEventDelegationFunction": I include this function to avoid the usage of the jQuery library, that is, to avoid to include it as another content script in our WebExtension. If you do all the above, you can see that, when you double click the content pages body, a modal dialog appear, with some input inside, and a button, which show you what you type in the input, and, additionaly, closes the modal dialog. The double click event can be replaced with the message that you receive from the background script, that is, the above is just a sample: in principle you can show the modal dialog when receive the message from the background script.

So, everything appear fine, right? Not completely. The problem can be, for example, to properly set a style for the input(s) and buttons of the dialog. Why? Because we are inside a content page, and, this content page have his own style... and this style can affect (and in fact do it) to our own style. The same can be said for all the Javascript stuff that we include in the content pages. We must carefully look at what Javascript we include, because the same problem: the content page Javascript can enter in conflicts with our own Javascript.

I start by including the jQuery library (to use event delegation, just to attach an event to the modal close dialog button), and, apparently works fine, even in my website, for example, which already uses jQuery. However, I am not sure about this approach... maybe jQuery don't enter in conflicts with my website, but, maybe can enter in conflicts with some other website. So you can play with the above code / stuff, follow my instructions, John, however, I am not sure if this can be the best approach... modify the content pages in this way... can cause some conflicts, difficult to handler in all the possible situations / content pages.

Maybe I go ahead to quickly to thinking in use some kind of modal dialog. Maybe the HTML form / controls can be appended to the content page's body, in order to appear at the top, for example, and, even in this case, probably we can see some unexpected behaviour in terms of the style that we apply to our inputs, because certainly we can't forget that the content pages have their own CSS style, that we can't control at all. Supose a content page have some CSS style which affects to "inputs", then our inputs become affected with that CSS style... and probably can be difficult to avoid that. Maybe by initialize the input CSS rules... (look for the "initial" values of the CSS rules), maybe we can finally get something working, but, I am not sure if after lot of work we can get something working exactly as we expected in all the content pages.

Please, play a bit with the above code / instructions, and, think maybe in another possible approach. For example, if we have the form / controls / inputs inside our WebExtension popup (in the main view or in other view), then the content page's scripts nor styles can affect to that controls, so, if that is possible, maybe is desirable to take an approach like that, instead to try to modify / append the content pages.

Hello John,

If I am not wrong, the background scripts can't show anything to the user, so, maybe what you can do is to send a message from the background script to the content script, and therefore, use something similar than the "right click menu" that we see here in this forum some days ago: I think you already know how to send a message from the background script to the content script: if you need some help in order to prepare the dialog HTML markup I can try to help you.

Hello John,

If you refers to the app's dialogs, it's possible to use some CSS code in the dialog's Show event, however, this can cause some scale problems with the controls inside the dialog: if we use pure HTML markup in the dialog (using an HTML control) then the scale problems don't appears. On the other hand, I am talking to reduce the height of the dialog, Jhon, no more, no less: the dialogs are designed to fit the app's views width and height, better said, we use the Boostrap CSS dialogs "as is", and, what we can do is to use the "Size" property of the dialogs, again, no more, no less.

Maybe you can prepare something different using a thirdparty Javascript / CSS library...

Hello John,

I have no experience with that, however, in the Google Chrome / chrome-extensions-samples at repository at Github, we can see this "simple" sample of context menu. If you pick the raw "sample.js" of the referred sample and copy it in the WebExtBackground app's event (or if you place it as a background script), certainly we can see a context menu of our WebExtension. You must study that "sample.js" code, John, as well the related API documentation.

Hello Amin,

About the minimize: when you use the minimize tool of AB1, the Incline CSS is also minimized, so, you no need to manually do it. About the possible bug, certainly, if we can find a way to reproduce it, then we can try to do something about!

Hello Amin,

This is quite rare... I mean, if I am not wrong, the duplicates CSS issue (which has been fixed in the past) are related with the CSS code generated by AB1, but, not the Inline CSS option! Talking about this Inline CSS option I simply can't reproduce the problem here... at least in the current release of AB1 I can't reproduce the problem... Please, Amin, try to reproduce the problem in a sample app... try to add some CSS code, compile the app, save it, repeat this operations, and, tell me if you can see the duplicates issue...

In fact its quite rare that you see a code like the below in the Inside CSS option:

... why? Because the Inline CSS code is not autogenerated by AB1... it's your CSS code... AB don't touch that CSS code... I just mention it because it's rare (double rare) that that comments appear in the Inline CSS option...

Hello Amin,

Sorry, but, I am not completely sure if can understand the problem, so I have some questions: 1º Are you tried to delete the "_Cache" folder? That solve the problem? 2º Can you describe a bit more the problem, please? 3º Can you prepare a sample app in which I can see the problem reproduced?

I am trying here to modify the Inline CSS option (we are talking of the previous generation of App Builder, not the current one), save the app, close it, reopen it, compile it various times, etc., and can't see nothing rare around...

I am not sure if this issue is related with a more or less "old" AB1 release... I can remember some "duplicates CSS" solved in newer releases... Note this from the product's history file:

But I am not sure if the above is the case... because, if I am not wrong, above I am not talking about the Inline CSS option... I am talking about the generated CSS files by AB, but not specifically (and I cannot remember) related with the Inline CSS option...

Hello John,

Yes;... I mean... I told you about the possible usage of a push button, and, thinking twice, probably the keyup event can be nice for this specific case and similar ones.

Hello John,

I think the best way is to use a Save button, below the text box, for example. Something like "Press here to save", so the user know that, if he want to save that text box, must press the Save button. Another possible way (but I probably prefer the first one) is to use the text box keyup event, so you can save the text box content just when the user type on it. I prefer the first way, however, probably the second one can be also take in consideration.

Hello John,

If you need to do something when a view is change to another view, then yes, the view's Hide event can be used, however, unfortunately there is nothing like a "popup close event" (which is what I understand that you wanted, do something when the WebExtension's popup is closed), but the browsers do not provide something like that, John.

Hello John,

The view's Hide event are mainly intended to be used when the user changes into another app's view. I think this also works as expected in WebExtensions. However, the WebExtensions itself do not offers something like an "on close popup" event, so, we simply can't use something like that.

I think the best can be to try to do the things in another manner, that is, don't rely in something like that. Maybe it's possible to do something about, but, probably a bit tricky. For example, you can attach a "body click" event in the WebExtension's content, because, when the user click the page, if the WebExtension's popup is open, become closed.

Hello Denis,

Glad to know that you got it. Certainly, must be different ways to enable the CORS permission in every server / language. Using the server's configuration, using the language "response" itself, and maybe more... Thanks for share one of them with us!

Hello Denis,

Unfortunately I have no experience with ISS nor ASPX (I touch a bit of C# in the past however), but, I will try to help you. My bet is that what fail here is the lack of CORS permissions. The behaviour of the HTTP control that you describes probably means that CORS are not well configured in the server side, and, you must do it in order to properly communicate your app with the server.

Please, take a look at this website: https://enable-cors.org/server.html, or, anyway, try to search how to configure the CORS permissions in ISS / ASPX, because I think this is what must be done: I am not sure if you can do it in the same ASPX script (by some properties of methods of the "Response" object), or if you must configure the server in another way, directly touching the server's configuration. For example, in PHP we can do that: configure a script in order to set the CORS permissions, so we no need to touch the configuration of the server (Apache, etc.). Probably it's possible to do it also in an ASPX script.

Hello John,

Yes; certainly we no need to add "options" into the select: we must deal with the "items" property, so, for example, we can change the items in the select in this way:

Or we can add a new item to the select in this way (remember, "items" is an Array variable):