Problem with window.getSelection

About a week ago, some sort of update has broken my web extension, bbCode for Web Extensions (bbCodeWebEx).

While doing something like adding tags to a piece of text still works just fine in compose mode (though it serves no purpose there, because you cannot add tags directly), in HTML editing mode, it is not picking up the selected text.

Specifically, if I highlight a text, and right click to add a tag, this line of code is supposed to, and has until about a week ago, get the value of the selected text:

let currentSelection = window.getSelection().toString().trim();

Gives me the selected text in the compose window, and on other websites, but it gives me ​<empty string>​ in the HTML editing window.

Anyone know what might be causing this or if there might be a work around?

Also, am I the only one who thinks that chasing Google’s regular changes that brake stuff is a major PITA?

You are referring to google and a HTML editing window? What exactly are you referring to? A specific editor?

Google Blogger (Blogspot.com) has an editor that has a WYSIWYG mode, and a mode in which one can edit the HTML code directly.

They updated both earlier this year, and in the past week, some update to their HTML editor appears to have broken window.getSelection.

I continues to work in their WYSIWYG mode, so a recent update on their HTML mode broke something.

I am looking for one of two things:

  • A good work around, I am looking at using clickedElement.selectionStart among other things.
  • What exactly Google did to break the page, which I cannot determine.

Since I have not ported this extension to Chrome, I cannot determine if the problem is Goggle is not playing nice with WebExtensions, or if Google is not playing nice with Firefox.

Maybe the selection is in a textarea. You probably have a different code path for textarea controls.

I actually do have a different code path for non-https text areas.

I would think that this would be a major change though, and they just rolled whatever this is out about 2 weeks ago in a silent update.

When they rolled out the new blogger editor I actually had to switch away from that.

I will check out the text area possibility though.

Something interesting digging through the console log, while
let currentSelection = window.getSelection().toString().trim();
gives no output,
let currentSelection = window.getSelection();
gives the following output:

Selection
anchorNode: <div style="overflow: hidden; positi…top: 4px; left: 1107px;">
anchorOffset: 0
caretBidiLevel: 0
focusNode: <div style="overflow: hidden; positi…top: 4px; left: 1107px;">
focusOffset: 0
isCollapsed: true
rangeCount: 1
type: "Caret"
<prototype>: SelectionPrototype { getRangeAt: getRangeAt(), addRange: addRange(), removeRange: removeRange(), … }

It looks like there is some sort of obfuscation on the page.

Why oh why does Google make everything so damn complex.

Ok, I’ve sound a solution that a Firefox screen reader uses. It will read the text, but I’m unclear as to what is happening at a programming level.

Native Text to Speech -TTS uses the following call to get selected text:

browser.contextMenus.onClicked.addListener(function(info, tab) {
	tabId = tab.id;
	menuId = info.menuItemId;
	console.log(menuId)
	texT = info.selectionText;
	browser.tabs.sendMessage(
		tabId,
		{
			command: "test"
		}
	).catch(function(aaa){
		if (aaa.toString().includes("connection") == true){
			let speak = browser.tabs.executeScript({
				file: "data/speak.js",
				//frameId: true
			});
			speak.then(onExecuted)
		}else{
			onExecuted()
		}
	})
});

And this does read the selected text in the HTML edit window.

I don’t quite get the notation (I’m a lousy programmer), so I’m not sure how this works, and if there would be a drop in to replace window.getSelection in my extension.

I use:

		browser.runtime.onMessage.addListener(function(commandString) {
			CommandParse(commandString)}); 

To get my program running.

I’ve forgotten half of what I knew about JavaScript in the past year.

This uses the “selectionText” you get from the context menu API, which is passed whenever a selection is right-clicked:

So, I would attach this to the listener, and pass the variable to my command parsing function.

Got it.

Thanks.

I’ve found a solution that works, it appears that
txtcont = document.activeElement.value;
gets the text value.

One odd thing is that it inserts a zero width space &#8203;

So this:

Becomes this when adding the [b] tag:

The red dot is the zero width space.