645506 - widgets should be auto-resizeable based on content

Status: RESOLVED WONTFIX

(Add-on SDK Graveyard :: General, enhancement)

Description

[Chris Pinard]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16
Build Identifier: 

It's nice that you can specify the width of a widget, but that doesn't help much if you don't know just how wide the widget should be. (For example, if it's an icon and a string of arbitrary length, like a username.) It would be nice if there were either a way to set a widget so that its size changed with its content/styles automatically, or a way to calculate how much space a widget will need based on content/styles so that the width property could be adjusted manually.

(If there's already a way to calculate the width without adding code to the widget object, adding that to the widget documentation would be great.)

Reproducible: Always

Comment 1

[George]

fwiw, my add-on uses offsetWidth to "measure" text content displayed by widget

Comment 2

[Chris Pinard]

Hm. Interesting concept, but I can't seem to find any way to get to the DOM of the widget content to query the offsetWidth. Could you elaborate on how you do that?

Comment 3

[George]

Include a span tag in your widget content to hold the text. Then your content script can do something like:

// Get span.
var displayString = document.getElementById('spanId');

// Clear existing text.
while ( displayString.firstChild ) {
    displayString.removeChild(displayString.firstChild);
}

// Set new text.
var foo = 'bar';
displayString.appendChild(document.createTextNode(foo));

// Emit width back to main.js.
self.port.emit('width', displayString.offsetWidth);

Comment 4

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Probably not going to happen for 1.2, but doesn't sound like it would take much to land if we run out of things to land for 1.2.

Comment 5

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

(Pushing all open bugs to the --- milestone for the new triage system)

Comment 6

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Adding a triage flag to get confirmation for this bug.

Comment 7

[Chris Pinard]

I tested grbradt's suggestion back when it was first made, and it improves my situation slightly compared to before I'd filed the bug, but either I'm missing something, or it's still not quite right. I haven't had time to chase it down any further since. Put simply, it works, but only for the first word in the widget content. Any words after the first are still technically in the widget, but are hidden by the widget not resizing itself large enough. It doesn't seem to be a matter of absolutely limited size; a single word can be as long as it likes and it resizes fine.

(So, for instance, in the example code below, the first two strings cycle in just fine; the third just shows "more"; the fourth just "enthusiastic"; and the mighty monster fifth string shows up in its entirety because for all its size, it's still only one word.)

I just updated to addon sdk 1.1 and retested, and this is still the case.

Example code:

data/widget.html (about as simple as it gets):
-----
<span id="wtest-span"></span>
-----

data/width.js:
-----
self.port.on('update', function(stuff) {
	var mywidget = document.getElementById("wtest-span");

	while (mywidget.firstChild) {
		mywidget.removeChild(mywidget.firstChild);
	}

	mywidget.appendChild(document.createTextNode(stuff.content));

	self.port.emit('width', {width: mywidget.offsetWidth});
});
-----

lib/main.js:
-----
const widgets = require("widget");
const self = require("self");

exports.main = function(options, callbacks) {
	console.log(options.loadReason);

	var stufflist = ["stuff", "things", "more things", "enthusiastic walks through the woods", "enthusiasticwalksthroughthewoods"];
	var stuffidx = -1;
	
	function nextthing() {
		stuffidx = stuffidx + 1;
		if (stuffidx >= stufflist.length) {
			stuffidx = 0;
		}
		console.log(stufflist[stuffidx]);
		return stufflist[stuffidx];
	}

	function updatewidget(mywidget) {
		mywidget.port.emit('update', {content: nextthing()});
	}

	var widget = widgets.Widget({
	  id: "wtest-widget",
	  label: "Mozilla website",
	  contentURL: self.data.url("widget.html"),
		contentScriptFile: self.data.url("width.js"),
		onClick: function() {
			updatewidget(this);
		}
	});

	widget.port.on('width', function changewidth(width) {
		console.log("The width is " + width.width);
		widget.width = width.width;
	});

	updatewidget(widget);

	console.log("The add-on is running.");
};
-----

Comment 8

[George]

You can also use the canvas element for your widget content. It has a measureText() method. I now use this, and it works fine.

Comment 9

[George]

Attachment: Widget example using canvas element

Comment 10

[Chris Pinard]

(In reply to George from comment #8)
> You can also use the canvas element for your widget content. It has a
> measureText() method. I now use this, and it works fine.

Well, that's an interesting approach -- I haven't tried it myself, but I opened up your Canadian Weather add-on and saw how you did it -- and I suppose it works, but it seems a bit overkill for what would otherwise be just a span with an img and some text.

Comment 11

[Dave Townsend [:mossop]]

Making sure we look at this in the next triage session

Comment 12

[Dave Townsend [:mossop]]

Waiting on Matteo to look at this

Comment 13

[Matteo Ferretti [:zer0] [:matteo]]

We're in the middle of moving the Add-on bar, I would say if this bug is not critical we should postpone it. At the moment I'm just moving the Add-on bar, so the behavior would be the same in the first iteration, but in accordance with UX the Add-on bar will be able to display only a max width of 3 / 4 icons per widget. I think we should discuss this bug with the UX as soon as we're going to implement the new max width for the Add-on bar.

Comment 14

[Jim Jeffery not reading bug-mail 1/2/11]

This will seriously harm ForecastFox.  I currently have 8 icons showing as that's how I have it configured to match my use case.  Limiting to 3 or 4 icons would leave me only the Radar Icon, and current readings, and 'day forecast' only for the current day.  I now see day and evening for 2 days out creating 8 icons.  If there is a severe weather situation it makes my use grow to 9 icons.

IMO a variable length addon bar will look 'silly' and appear to be just 'tacked' onto the browser, full width is not hurting anything as it was created as far as I recall to replace the ripped out statusbar but with more flexibility. 

Matteo where are you 'moving' the addon bar to ?

Comment 15

[Chris Pinard]

Yeah, uh, seriously, what? The entire point of the Add-on Bar, IMO, is for add-ons that need more space than just an icon or two that could tossed into the nav bar.

The current version of my LJlogin extension supports logins for seven different sites, each of which needs its own icon and (by default but optional) text label for the username. If I ever get around to doing the 3.0 rewrite -- which is what I've been looking at the Add-on SDK for in the first place -- one of the features I have planned is moving the multi-site support from a hard-coded list to something more like Greasemonkey or Stylish, where a user downloads/installs a bit of config for the sites they want to use.

Granted, I don't know if there are still any LJ-code sites other than the ones I support, but I've been asked for it in the past, and it opens up the potential for a user having who knows how many widgets. Is this going to be the point that we finally have to start creating our own toolbars?

Comment 16

[Dave Townsend [:mossop]]

(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #14)
> This will seriously harm ForecastFox.  I currently have 8 icons showing as
> that's how I have it configured to match my use case.  Limiting to 3 or 4
> icons would leave me only the Radar Icon, and current readings, and 'day
> forecast' only for the current day.  I now see day and evening for 2 days
> out creating 8 icons.  If there is a severe weather situation it makes my
> use grow to 9 icons.

Seems like this could be handled by multiple widgets.

> IMO a variable length addon bar will look 'silly' and appear to be just
> 'tacked' onto the browser, full width is not hurting anything as it was
> created as far as I recall to replace the ripped out statusbar but with more
> flexibility. 
> 
> Matteo where are you 'moving' the addon bar to ?

The UX plans to move the add-on bar into the toolbar area where it can't take up the fill width.

(In reply to Chris Pinard from comment #15)
> Granted, I don't know if there are still any LJ-code sites other than the
> ones I support, but I've been asked for it in the past, and it opens up the
> potential for a user having who knows how many widgets. Is this going to be
> the point that we finally have to start creating our own toolbars?

The new UX plans includes support for toolbars if add-ons want them.

I encourage you to take discussion around these plans to the thread in the mailing list: https://groups.google.com/d/topic/mozilla-labs-jetpack/XOxg4rpHen0/discussion

Comment 17

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to Dave Townsend (:Mossop) from comment #16)
> Seems like this could be handled by multiple widgets.

But only if we can make sure they are not scrambled in order. I have seen this a lot with MemChaser when we had two widgets for the general information and the logger icon. All the time other SDK based add-ons moved in-between our two widgets. That totally removes the binding between widgets of the same add-on.

Comment 18

[Dietrich Ayala (:dietrich)]

This bug kills me. Would be so nice to have as a configurable option for add-on bar widgets.

Comment 19

[George]

As a follow-up to my comment regarding using the canvas element for your widget content, it seems now that NoScript will block the display of a widget using this method. If you turn on 'Allow scripts globally' in NoScript, the widget then displays properly. Arrrgh!

Comment 20

[Matteo Ferretti [:zer0] [:matteo]]

Based on UX feedback, this bug is probably a WONTFIX. Stephen Hoarlander said:

"I think we should either support a standard widget width of 64px or, as suggested, a few standard widths: 32px, 48px, 64px.

I don't like the idea of the widget auto resizing itself either because the whole toolbar would be constantly shifting."

Notice the discussion take as prerequisite that we're moving the Add-on Bar in the navigation bar (see bug 787384, and more generally bug 695913).

Comment 21

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This would basically be still valid for add-ons which will have their own toolbar and display text in one of the widgets. You do not want to reserve to much space but also don't want that content is cut-off.

Comment 22

[Matteo Ferretti [:zer0] [:matteo]]

The UI issue raised by Stephenis valid also for Toolbar's widget. If we allow that, the "whole toolbar (widget in that case) would be constantly shifting".

However, Toolbar's widget are not well defined yet, so based on the current UX feedback my suggestion is close this bug until we will work on bug 787390 and see if it makes sense reopen this one and link as dependency.