Note: There are a few cases of duplicates in user autocompletion which are being worked on.

WebExtensions: chrome.windows.create creates windows with incorrect size if window does not have title bar

UNCONFIRMED
Unassigned

Status

()

Toolkit
WebExtensions: Frontend
P4
normal
UNCONFIRMED
a year ago
7 months ago

People

(Reporter: dw-dev, Unassigned)

Tracking

47 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: triaged[windows])

(Reporter)

Description

a year ago
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160604131506

Steps to reproduce:

I have migrated my Tile Tabs add-on to use the new WebExtensions API.

This add-on does a lot of window create/update operations.  I have noticed that chrome.windows.create does not create windows with the correct dimensions, if the "Title Bar" has been turned off in the Firefox Customize window.

For example, try executing this code, when the "Title Bar" has been turned off:

    chrome.windows.create({ type: "normal",
                                        left: 100, top: 200,
                                        width: 400, height: 600 },
    function(newwin)
    {
        .....
    });



Actual results:

The new window properties are correctly set:

    newwin.left == 100
    newwin.top == 200
    newwin.width == 400
    newwin.height == 600

The new window is created at the correct position:  left: 100, top: 200

The new window dimensions are INCORRECT:  width: 403, height: 602



Expected results:

The new window dimensions should be:  width: 400, height: 600
Is there a reason that you've been filing bugs in Firefox :: Untriaged rather than Toolkit :: WebExtensions? It's much easier for us to track them if you file them there directly.
Component: Untriaged → WebExtensions
Product: Firefox → Toolkit
(Reporter)

Comment 2

a year ago
Kris,

When I first started reporting WebExtensions bugs, I didn't know that was allowed to triage them.  It's not something I had done when previously reporting XUL/XPCOM bugs.  However, a few bugs ago, someone else mentioned that it would be helpful if I triaged WebExtensions bugs.  Unfortunately, through force of habit, I have forgotten to do this, but I will in future.

Actually, I also have a question.  I have found a few situations where some of the WebExtensions API calls fail or cause unexpected mis-behaviours.  The most recent was when calling chrome.windows.create from within chrome.windows.getLastFocused from within chrome.storage.local from within chrome.runtime.onMessage.  However, this works if you break the execution in chrome.storage.local with setTimeout(...,0).  My view was that this bug was too obscure to bother reporting.  Would you prefer that I reported such obscure bugs?
Flags: needinfo?(kmaglione+bmo)
(In reply to dw-dev from comment #2)
> Actually, I also have a question.  I have found a few situations where some
> of the WebExtensions API calls fail or cause unexpected mis-behaviours.  The
> most recent was when calling chrome.windows.create from within
> chrome.windows.getLastFocused from within chrome.storage.local from within
> chrome.runtime.onMessage.  However, this works if you break the execution in
> chrome.storage.local with setTimeout(...,0).  My view was that this bug was
> too obscure to bother reporting.  Would you prefer that I reported such
> obscure bugs?

Yes, please report them.
Flags: needinfo?(kmaglione+bmo)

Updated

a year ago
Priority: -- → P4
Whiteboard: triaged

Updated

8 months ago
Component: WebExtensions: Untriaged → WebExtensions: Frontend

Updated

8 months ago
Whiteboard: triaged → triaged[windows]
You need to log in before you can comment on or make changes to this bug.