Open
Bug 1284273
Opened 8 years ago
Updated 9 months ago
WebExtensions: chrome.windows.create creates windows with incorrect size if window does not have title bar
Categories
(WebExtensions :: Frontend, defect, P5)
Tracking
(Not tracked)
UNCONFIRMED
People
(Reporter: dw-dev, Unassigned)
Details
(Whiteboard: triaged[windows])
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
Comment 1•8 years ago
|
||
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
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)
Comment 3•8 years ago
|
||
(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•8 years ago
|
Priority: -- → P4
Whiteboard: triaged
Updated•8 years ago
|
Component: WebExtensions: Untriaged → WebExtensions: Frontend
Updated•8 years ago
|
Whiteboard: triaged → triaged[windows]
Updated•6 years ago
|
Priority: P4 → P5
I don't agree with lowering the priority of this bug. The windows.create() API is meant to create a window of the specified size. It should do this correctly whether or not the window title bar is showing.
Updated•6 years ago
|
Product: Toolkit → WebExtensions
Comment 5•3 years ago
|
||
Hello, I am new to contributing to Bugzilla can you assigned me to this issue so that I can learn to fix these bugs and also suggest to me how can Is start working on this bug to fix it.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•