Webextension and custom dialog box on background script

Ahorre dinero comprando nuestros paquetes de NeoPlugins. ¡Cinco, Diez e incluso nuestra colección entera a un precio increíble!

DecSoft HTML Compiler incluye un conveniente Compilador por línea de comandos para compilar sus apps desde la consola.

Cree modernas apps y juegos HTML a otro nivel haciendo cosas que incluso las modernas apps y juegos HTML no pueden.

¡Eche un vistazo a nuestro canal de YouTube y suscríbase para recibir notificaciones sobre nuevos vídeos!

Compile, convierta sus modernas apps y juegos HTML en programas ejecutables sin dependencias para Microsoft Windows.

Cree apps y expanda sus capacidades usando el lenguaje más popular del mundo: Javascript.

Cree apps multiplataforma con DecSoft App Builder, incluyendo Android e iOS, con la misma base de código.

DecSoft App Builder integra un asistente de Open AI para ayudarle mientras desarrolla sus apps.

Los NeoPlugins de DecSoft tienen versiones "designtime" y "runtime" para reducir el tamaño de sus apps.

Los plugins oficiales de Apache Cordova se incluyen de serie y hay cientos de ellos disponibles para su uso.

Diseñe para pantallas pequeñas y distribuya también (sin cambios) en dispositivos como tablets.

DecSoft NeoPlugins pone sus proyectos de VisualNeo en otro nivel con +1.000 nuevas acciones para sus apps.

DecSoft App Builder incluye un conveniente Compilador por línea de comandos para compilar sus apps desde la consola.

Ahorre tiempo, recursos y dinero creando apps para Android, iOS y más con la misma base de código.

DecSoft HTML Compiler es fácil de usar: personalize su proyecto y compile sus apps y sus juegos rápidamente.

¡Eche un vistazo a algunas de preguntas más frecuentes sobre nosotros y nuestros productos!

John Clarke

I am trying to figure out how to create a custom dialog box on the background script. This dialog will contain a drop down, a text box, an OK button and a cancel button. I would then call a function on this script to display it.

DecSoft

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.

Purchase one or more licenses of our products if they are useful to you!

John Clarke

I can send the message from the background script to the content script. It would be really useful to have an example of a popup that appears when the content script receives the message from the background script.

DecSoft

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:

#modal-dialog-instance
{	
  color: black;
  width: 500px;
  height: 400px;
  background-color: white;	
}

#close-dialog-modal-instance-container
{
  margin-top: 60px;
  text-align: center;	
}

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:

// Taken from: https://flaviocopes.com/javascript-event-delegation/
// This avoid to use jQuery for event delegation, that is, this avoid to include jQuery in the content pages
window.myEventDelegationFunction = (selector, eventType, childSelector, eventHandler) => {
  const elements = document.querySelectorAll(selector)
  for (element of elements) {
    element.addEventListener(eventType, eventOnElement => {
      if (eventOnElement.target.matches(childSelector)) {
        eventHandler(eventOnElement)
      }
    });
  }
};

// When we double click in the body, show a modal with our form (inputs) inside
document.body.addEventListener('dblclick', function () {
  window.dialogModalInstance = basicLightbox.create(`
    <div id="modal-dialog-instance">
     <div id="close-dialog-modal-instance-container">
      <form action="none">
       <input id="my-webextension-dialog-input-1" type="text" placeholder="Type something here">
      </form>
      
      <button id="close-dialog-modal-instance-button">Get the input value and close this dialog</button>
     </div>
    </div>
  `,
  {
    closable: false
	});

  window.dialogModalInstance.show();
});

myEventDelegationFunction('body', 'click', '#close-dialog-modal-instance-button', event => {
  event.preventDefault();
  alert('You type: ' + document.querySelector('#my-webextension-dialog-input-1').value);
  window.dialogModalInstance.close();
});

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.

Purchase one or more licenses of our products if they are useful to you!

John Clarke

I was just wondering about the following ideas:

1. Is it possible to send a message from the background script to the WebExtension instead of to the content ? If so how?
2. If number 1 is possible is it possible to get the extension to display its user interface? The only difference being that it will show a different form.

DecSoft

Hello John,

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


// This code in a WebExtension background script or the app's WebExtBackground event

chrome.contextMenus.create({"title": "Open the WebExtension popup", "onclick": function () {
  window.localStorage.setItem('required-app-view', 'view2');
  chrome.browserAction.openPopup();
}});


// This code in the app's main view Show event:

var
  appView = localStorage.getItem('required-app-view');

if (appView != null) {
  app.showView(appView);
  window.localStorage.removeItem('required-app-view');
}

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:


 // Placed in a WebExtension background script (or the WebExtBackground app's event)

chrome.contextMenus.create({"title": "Open the WebExtension in new tab", "onclick": function () {
  window.localStorage.setItem('required-app-view', 'view2');
  chrome.tabs.create({'url': chrome.extension.getURL('www/index.html')}, function(tab) {
    // Tab opened.
  });
}});


// This code in the app's main view Show event:

var
  appView = localStorage.getItem('required-app-view');

if (appView != null) {
  app.showView(appView);
  window.localStorage.removeItem('required-app-view');
}

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.

Purchase one or more licenses of our products if they are useful to you!

DecSoft

Hello John,

Before I leave you as a task how to create a tab from a content script (in case you need that, that is, if you did not want to use a context menu item created in a background script). Here is a way to create a new tab from content scripts. The point is to send a mesage to the background script in order to create the new tab. Look at the below code:


// This is placed in a content script

document.body.addEventListener('dblclick', function() {
  chrome.runtime.sendMessage({id: "open-tab"});
}, false);


// This is placed in a background script

chrome.runtime.onMessage.addListener(function(request, sender, sendResponse) {
  if (request.id == "open-tab") {
    chrome.tabs.create({'url': chrome.extension.getURL('www/index.html')}, function(tab) {
      // Tab opened.
    });
  }
});

Purchase one or more licenses of our products if they are useful to you!

DecSoft

Hello John,

Before I suggest you to use the app's MaxWidth and MaxHeight properties to avoid the possible "scale problem" in your app's view opened in a new tab. This can be certainly a possible way, however, there is another one: it's also possible to use the "app.setAppFixedStyle()" method in the app's view Show event, so, we change to the fixed style, avoiding the possible "scale problem". You can try with all of these possible approaches and take the best for your specific case.

Purchase one or more licenses of our products if they are useful to you!

John Clarke

Thanks for your help regarding this matter. I decided to go for the options where the dialog is opened on another tab. The only issue that I have is that this other tab doesn't seem to have access to the same localstorage as the plugin. How can I resolve that ?

DecSoft

Hello John,

Are you sure that there is not the same local storage? I made some tests and apparently we have the same local storage, John! Can you mention here what exactly method are you using to opened in another tab?

Purchase one or more licenses of our products if they are useful to you!

John Clarke

Apologies, after I updated my code and compiled it I didn't clean the cache. I have just tried it again and it worked.

DecSoft

Hello John,

No problem! One thing what I try the local storage, so for that my surprise. But the point is that you got it!

Purchase one or more licenses of our products if they are useful to you!

Todo el mundo puede leer el foro de soporte de DecSoft para aprender del mismo, sin embargo, sólo los clientes de DecSoft pueden abrir nuevos hilos. Compre una o más licencias de productos de DecSoft y obtendrá este y otros beneficios.