Closed
Bug 574638
Opened 14 years ago
Closed 14 years ago
Browser client area doesn't paint when restoring to maximized state
Categories
(Core :: Widget: Win32, defect)
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | betaN+ |
People
(Reporter: jmjjeffery, Assigned: jimm)
References
Details
(Keywords: regression, relnote)
Attachments
(7 files, 2 obsolete files)
With the landing of bug 513162, when the browser is started up, the entire area at the top of the browser window is gray displaying no Chrome UI at all, until after the browser, and any tabs are loaded from say sessionstore.
Comment 1•14 years ago
|
||
Confirmed. Happens to me too.
Comment 2•14 years ago
|
||
Only with D2D/DW.
Reporter | ||
Comment 3•14 years ago
|
||
(In reply to comment #2) > Only with D2D/DW. No, it happens whether dw/d2d is on or off..
(In reply to comment #3) > (In reply to comment #2) > > Only with D2D/DW. > > No, it happens whether dw/d2d is on or off.. Correct, it's happening on WinXP classic as well. ~B
Is this fixed now?
(In reply to comment #5) > Is this fixed now? I'm still seeing this issue on Windows XP Classic but to be clear in my case I see all black where the tabbar, address bar, toolbar and file menu would normally be until after the browser, and any tabs are loaded from say sessionstore. BUILD: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100629 Minefield/4.0b2pre ( .NET CLR 3.5.30729; .NET4.0C) ID:20100629135842 ~B
Reporter | ||
Comment 7•14 years ago
|
||
(In reply to comment #5) > Is this fixed now? No..I still see it, and I don't use d2d stuff at the moment. It looks really ugly when the browser starts up, a large gray border, with a white middle, and no UI at all till the tabs from the previous session are almost all loaded.
Assignee | ||
Comment 8•14 years ago
|
||
any chance you guys could grab a print screen screen shot of what this looks like and post?
Reporter | ||
Comment 9•14 years ago
|
||
Yeah I can try when I get home from work, about 3 hrs...
Comment 10•14 years ago
|
||
Do we know what set of users this affects?
Comment 12•14 years ago
|
||
Is this on a clean profile? Juan, can we get someone to help us get a clear STR? Sounds like we should be testing WinXP in Classic Mode - Dao usually tests that, though! :)
Comment 13•14 years ago
|
||
This is the issue I assumed this bug was about. It sits like this for about a second or two on my Windows 7 x64 laptop with Intel GMA4500 graphics.
Reporter | ||
Comment 14•14 years ago
|
||
Screen shot Win7 x64 ATI on-board HD3200 video chip, AMD Phenom II Quad The gray border can last from a few seconds to several. I have a set of 11 tabs I usually start with the browser.
Reporter | ||
Comment 15•14 years ago
|
||
New profile, no tabs,bookmarks - shows a quick splash of gray border on start, so I don't think its a profile issue.
Comment 16•14 years ago
|
||
Not a beta 1 blocker, but we'll relnote it and try to get it for an early beta.
Updated•14 years ago
|
Component: Layout → Widget: Win32
QA Contact: layout → win32
Assignee | ||
Updated•14 years ago
|
Comment 17•14 years ago
|
||
Is anyone else experiencing slower than normal loading time for the browser chrome? When it's all grey, clicking anywhere within the window or title bar makes it unresponsive.
Comment 18•14 years ago
|
||
Not really a major issue but on the release notes it says this bug only happens with Windows classic theme but it happens with any theme actually.
blocking2.0: final+ → beta2+
Assignee | ||
Updated•14 years ago
|
Updated•14 years ago
|
blocking2.0: beta2+ → betaN+
Comment 19•14 years ago
|
||
It might be worth mentioning that on Word 2010, the glasses areas load as grey too, while the content areas load as white. At times when Word 2010 just works, you don't notice this at all due to the loading panel. So I'm not confident of how much we can do to eradicate this completely.
Comment 20•14 years ago
|
||
Since running the Firefox 4 Betas (both 1 and 2) I have experienced the same problem, with the whole interface appearing grey/white for several seconds until the UI loads fully. It doesn't look good! OS is Windows 7 64Bit
Comment 21•14 years ago
|
||
Comment 22•14 years ago
|
||
This minor annoyance at first seems to be getting worse as builds go on. At first I only saw the grey/white boxes after a Windows restart, now it happens at every Minefield restart. I am running Windows 7 64 Bit.
Comment 23•14 years ago
|
||
(In reply to comment #22) I've noticed that also. This regression also really slows down startup time. It ranges from 3-30 seconds. Clicking anywhere in the gray space makes FF unresponsive.
Assignee | ||
Comment 24•14 years ago
|
||
This may be addressed by the patch in bug 579421. Will have to wait to see once it lands.
Comment 25•14 years ago
|
||
(In reply to comment #24) > This may be addressed by the patch in bug 579421. Will have to wait to see once > it lands. What's the relationship between the two bugs?
(In reply to comment #25) > What's the relationship between the two bugs? Both deal with early rendering of the browser window. Bug 5679421 just landed, btw.
Comment 27•14 years ago
|
||
(In reply to comment #26) Apparently they weren't connected since this still happens. Was the regression window ever found?
Comment 28•14 years ago
|
||
I know we've seen the white area in bug about resizing a window always revealed the same white rectangle, so correlate that with another example i just saw was if I had a window open long and skinny, it showed up in the grey area as white rectangle in the same area. The white area seems to still be related to previous or prior windows dimension paints being open before the main window displays.
Comment 29•14 years ago
|
||
I think you're onto something Dennis, as occasionally I get a "URL cannot be loaded" dialogue box before the GUI has even loaded properly.I think this bug may be fixed by loading the GUI first and then loading the content/accessing the session store. But my amateur analysis isn't worth much.
Comment 30•14 years ago
|
||
Well, Jim, Mike, I might have found some steps to reproduce the white area on grey at least with session restore (which may or may not matter) As I said a moment ago: I had window of normal mode dimensions in a previous session of a long and skinny window and have session restore running. 1. Run the browser in Maximized mode (only 1 window open). 2. Close the browser from the X Maximized window. 3. Choose Save and Quit. 4. It restarts (to restore my session). But its not being restore as Normal window but Maximized, this is expected. 5. Watch the window first paints the normal window mode as white on grey background as it starts up and then it loads the window as Maximized and paints chrome/content.
Comment 31•14 years ago
|
||
I know it needs to be refined a bit.. my window in normal mode is long and skinny before I run the browser in Maximized mode, step 1. Also, I just tested Step 3 using only Quit - to not restore tabs, and it still does it. My start up option is set to show my homepage, and remember history - not that either matter per say.
Comment 32•14 years ago
|
||
The grey UI areas looks relative to changing the normal mode dimensions. (In reply to comment #29) > I think you're onto something Dennis, as occasionally I get a "URL cannot be > loaded" dialogue box before the GUI has even loaded properly.I think this bug > may be fixed by loading the GUI first and then loading the content/accessing > the session store. But my amateur analysis isn't worth much. Could be, I guess we'll let Jim take a look. The other thing I've seen related to random transparent-ness, I thought we had bug on that too already, as sometimes I get chrome paints over my windows 7 gadget, and content paints under the other gadget. ie a Z-order bug.
Comment 33•14 years ago
|
||
I get a mass of grey and a white bit on every start. The size of the white bit differs.
Assignee | ||
Comment 34•14 years ago
|
||
So, based on the comments here and all the screenshots, I'm correct is assuming this is a restore session w/ a maximized window specific bug?
Assignee | ||
Comment 35•14 years ago
|
||
(In reply to comment #34) > So, based on the comments here and all the screenshots, I'm correct is assuming > this is a restore session w/ a maximized window specific bug? * "am I correct in assuming"
Comment 36•14 years ago
|
||
Well, I'm thinking its related at least to Maximized, I didn't see Normal Mode do it since it came up ok then. Session Restore I'm not sure yet it may or may not be related. I also noticed Grey and White UI doing another type of activity: Again, start with the long and skinny vertical normal window. Place it on the left size of the monitor. Then use the resize on the right border and drag it across your screen really fast, and drag it back, repeat that. You see the Content area is painting grey first, and the chrome is painting white first.
Assignee | ||
Comment 37•14 years ago
|
||
(In reply to comment #36) > I also noticed Grey and White UI doing another type of activity: > > Again, start with the long and skinny vertical normal window. Place it on the > left size of the monitor. Then use the resize on the right border and drag it > across your screen really fast, and drag it back, repeat that. You see the > Content area is painting grey first, and the chrome is painting white first. I've noticed this as well, it's new in 4.0. File a bug with a screen cap maybe? This was present before the titlebar code landed. Might have something to do with 3d accel or layers.
Assignee | ||
Updated•14 years ago
|
Summary: UI is gray on startup of browser → Browser client area is doesn't paint when restoring to maximized state
Comment 38•14 years ago
|
||
I get a gray and white folder looking image on start up of Minefield. This has been going on for weeks. After I restart my PC, I have to stare at this for upwards of 40 seconds before Minefield finally starts. This is really annoying and should be fixed as soon as possible.
Comment 39•14 years ago
|
||
To comment 38, below is what I see after I restart my windows 7 8GB ram X64 PC. file:///D:/Documents/Camtasia%20Studio/Minefield%20Startup/Minefield%20Startup.html
Comment 40•14 years ago
|
||
Sorry but this is to comments 38 and 39. You should be able to view this start up video: http://s20.photobucket.com/albums/b243/TK-1913/?action=view¤t=MinefieldStartup.mp4
Assignee | ||
Updated•14 years ago
|
Summary: Browser client area is doesn't paint when restoring to maximized state → Browser client area doesn't paint when restoring to maximized state
Assignee | ||
Comment 41•14 years ago
|
||
We recently landed bug 130078, which removed sub widgets from the main view. Curious if that work affected this bug?
Assignee | ||
Comment 42•14 years ago
|
||
(In reply to comment #40) > Sorry but this is to comments 38 and 39. You should be able to view this start > up video: > > http://s20.photobucket.com/albums/b243/TK-1913/?action=view¤t=MinefieldStartup.mp4 What version of fx 4.0 was this Gary? Have you tried a latest nightly?
Comment 43•14 years ago
|
||
(In reply to comment #41) > We recently landed bug 130078, which removed sub widgets from the main view. > Curious if that work affected this bug? I still see this problem in the latest nightlies. I'm currently using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100830 Firefox/4.0b5pre
Assignee | ||
Comment 44•14 years ago
|
||
(In reply to comment #43) > (In reply to comment #41) > > We recently landed bug 130078, which removed sub widgets from the main view. > > Curious if that work affected this bug? > > I still see this problem in the latest nightlies. I'm currently using > Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100830 > Firefox/4.0b5pre On an win7 aero desktop you see this? Can you describe what you're seeing?
Comment 45•14 years ago
|
||
This is what I'm seeing every time I startup Firefox. I'm using Win7 x64 with Aero on.
Comment 46•14 years ago
|
||
(In reply to comment #45) > Created attachment 470492 [details] > Grey UI on FF startup using Win7 Aero > > This is what I'm seeing every time I startup Firefox. I'm using Win7 x64 with > Aero on. I would clarify that the length of time this white/grey pattern shows up seems to be directly proportional to how many tabs/app-tabs FF is restoring on startup. But, even on a fresh profile with only one blank tab open, it still appears for a brief amount of time.
Comment 47•14 years ago
|
||
Sorry for the bugspam, but I thought this was important to capture: This is what I see when Firefox starts up and is restoring a single blank tab with a brand-new fresh profile with no extensions on the latest nightly. As you can see, getting the screenshot was hard, as the grey/white UI only shows up briefly as Firefox opens to maximized mode (that's the reason for the strange transparency and trapezoidal shape of the window - I captured this in mid-maximization). But, the problem gets much, much worse as more tabs have to be restored, to the extent that the grey/white UI sits on screen in maximized mode for a second or two before the normal Firefox UI and content appears.
Assignee | ||
Comment 48•14 years ago
|
||
I wonder if this is triggered by session restore somehow. If I open fx, maximize it, close it, and launch again, the window opens in the maximized state. I don't see a window transition from normal to maximized.
Comment 49•14 years ago
|
||
Comment on attachment 470492 [details]
Grey UI on FF startup using Win7 Aero
I see something like this when starting up on win7 with aero and firefox maximized using nightlies that have 130078.
Comment 50•14 years ago
|
||
(In reply to comment #48) > I wonder if this is triggered by session restore somehow. If I open fx, > maximize it, close it, and launch again, the window opens in the maximized > state. I don't see a window transition from normal to maximized. I'm not sure that the window is transitioning from normal to maximized, I think that the effect that I captured is simply Windows 7 animating the window opening. If I turn off the animation (Control Panel > System > Advanced System Settings > Advanced > Performance > Settings > Visual Effects > Animate windows when minimizing and maximizing), the grey UI appears instantly in maximized mode without the animation.
Comment 51•14 years ago
|
||
(In reply to comment #28) > I know we've seen the white area in bug about resizing a window always revealed > the same white rectangle, so correlate that with another example i just saw was > if I had a window open long and skinny, it showed up in the grey area as white > rectangle in the same area. > > The white area seems to still be related to previous or prior windows dimension > paints being open before the main window displays. Actually, this seems to hit the nail on the head for me. The white area is exactly the size/position of the Firefox window if it is in normal (non-maximized) mode. So, Jim, you may be right that it has something to do with the window being maximized upon startup.
Assignee | ||
Comment 52•14 years ago
|
||
Has anyone tried tweaking the initial paint refresh timer? In about:config, search for paint. (nglayout.initialpaint.delay) I think the default is around 250 msec.
Comment 53•14 years ago
|
||
(In reply to comment #52) > Has anyone tried tweaking the initial paint refresh timer? In about:config, > search for paint. (nglayout.initialpaint.delay) I think the default is around > 250 msec. I just tried values from 0 to 500, and it made no difference.
Comment 54•14 years ago
|
||
You might also want to try a very large value like 10000 to see if it makes the problem appear for longer maybe.
Comment 55•14 years ago
|
||
So, with 0, it was ~2 seconds of grey/white UI, and with 10000, it might have been slightly longer (maybe ~3 seconds?).
Assignee | ||
Comment 56•14 years ago
|
||
I think Dale mentioned this as well. If you shrink your window up into a small rect, then maximize, close, and launch, the white block is the size of the small normalized window. So we are definitely sizing the content area to some default, then resizing the window and content to maximized. But for some reason the two are out of sync, and we get the weird gray outer area with the white inner block. I'm pretty sure the second resize comes from nsXULWindow's OnChromeLoaded handler.
Assignee | ||
Comment 57•14 years ago
|
||
Another interesting question - if we delay our own painting using the refresh timer, where is this gray and white background getting painted?
Comment 58•14 years ago
|
||
Is there a place defined somewhere that should be grey? If could somehow change the color to white that would even make it less noticeable.
Comment 59•14 years ago
|
||
I always thought this bug was for the grey/white start-up issue. I apologise for my ignorance regarding that. Will that stuff now be handled by this bug or will a new one be filed?
Assignee | ||
Comment 60•14 years ago
|
||
(In reply to comment #59) > I always thought this bug was for the grey/white start-up issue. I apologise > for my ignorance regarding that. Will that stuff now be handled by this bug or > will a new one be filed? That's what this bug is about, we've just had some other slow startup issues mixed in a bit. But this bug is about exactly what you mention - gray/white blocks and the fact that they show up initially instead of chrome/content.
Assignee | ||
Comment 61•14 years ago
|
||
SetSizeMode(0) SetSizeMode(0) SetSizeMode(0) SetSizeMode(0) Move(604, 248) SetSizeMode(0) SetSizeMode(0) -> normal Resize(374, 430, 1) ResizeClient(0, 0, 358, 422, 0) ResizeClient(0, 0, 358, 422, 0) Show(1) SetSizeMode(2) -> maximized ResizeClient(0, 0, 2560, 1568, 0) Show(1) Hmm, we do get a resize while visible before setting the size mode. I'll have to track down who is making these calls.
Assignee | ||
Comment 62•14 years ago
|
||
Assignee | ||
Comment 63•14 years ago
|
||
w/o the rtl code from another patch.
Assignee | ||
Updated•14 years ago
|
Attachment #471625 -
Attachment is obsolete: true
Assignee | ||
Comment 64•14 years ago
|
||
I'll have try builds here in a bit if anyone would care to test.
Comment 65•14 years ago
|
||
I'll be happy to test whenever you have the win builds!
Comment 66•14 years ago
|
||
try build: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/jmathies@mozilla.com-8292376a5d27/
Comment 67•14 years ago
|
||
Well, this resizes faster, still gray background, but this looks like it regresses several bugs, it would be a return to the little white box rectangle on startup bug where the firefox menu is and the paint isn't updated so cursor shows up while editing a textbox as I can type faster than the cursor paints.
Comment 68•14 years ago
|
||
(In reply to comment #67) > the paint isn't updated so cursor > shows up while editing a textbox as I can type faster than the cursor paints. You can probably just ignore this, as this actually looks like fallout from initial landing of bug 240933 based on comments there.
Assignee | ||
Comment 69•14 years ago
|
||
(In reply to comment #67) > Well, this resizes faster, still gray background, but this looks like it > regresses several bugs, it would be a return to the little white box rectangle > on startup bug where the firefox menu is and the paint isn't updated so cursor > shows up while editing a textbox as I can type faster than the cursor paints. Hmm, I see the little white box in the initial paint too. :( It's basically the same thing, but since I'm not resizing the window to persisted size the white block is smaller, but still there.
Assignee | ||
Comment 70•14 years ago
|
||
(In reply to comment #69) > (In reply to comment #67) > > Well, this resizes faster, still gray background, but this looks like it > > regresses several bugs, it would be a return to the little white box rectangle > > on startup bug where the firefox menu is and the paint isn't updated so cursor > > shows up while editing a textbox as I can type faster than the cursor paints. > > Hmm, I see the little white box in the initial paint too. :( It's basically the > same thing, but since I'm not resizing the window to persisted size the white > block is smaller, but still there. Pushed another patch to try that gets rid of the gray.
Comment 71•14 years ago
|
||
(In reply to comment #70) > (In reply to comment #69) > > (In reply to comment #67) > > > Well, this resizes faster, still gray background, but this looks like it > > > regresses several bugs, it would be a return to the little white box rectangle > > > on startup bug where the firefox menu is and the paint isn't updated so cursor > > > shows up while editing a textbox as I can type faster than the cursor paints. > > > > Hmm, I see the little white box in the initial paint too. :( It's basically the > > same thing, but since I'm not resizing the window to persisted size the white > > block is smaller, but still there. > > Pushed another patch to try that gets rid of the gray. http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/jmathies@mozilla.com-ce5092626834/ This new build is better, I don't see gray at all. Though I'm not sure if resizing is slower or maybe choppy, probably need a few eyes to test it.
Assignee | ||
Comment 72•14 years ago
|
||
Simple fix. The first child widget we removed had a default background of white. With that gone, we see much more of our default background color, which was gray.
Attachment #471626 -
Attachment is obsolete: true
Attachment #472640 -
Flags: review?(neil)
Comment 73•14 years ago
|
||
Comment on attachment 472640 [details] [diff] [review] nix gray patch This line dates back to the original version on 1998-12-03, so I have no idea why those particular values were used. Nor do I see why this needs to be special-cased on Windows. I suggest just changing the values and adding a comment to explain why you want to specify a white background. By the way, I'm still noticing on my builds that maximised windows open at restored size and then maximise themselves. I thought there was a bug on that?
Attachment #472640 -
Flags: review?(neil) → review+
Assignee | ||
Comment 74•14 years ago
|
||
(In reply to comment #73) > Comment on attachment 472640 [details] [diff] [review] > nix gray patch > > This line dates back to the original version on 1998-12-03, so I have no idea > why those particular values were used. Nor do I see why this needs to be > special-cased on Windows. I suggest just changing the values and adding a > comment to explain why you want to specify a white background. > > By the way, I'm still noticing on my builds that maximised windows open at > restored size and then maximise themselves. I thought there was a bug on that? One of the obsolete patches here tried to address that. In xul window, the code positions and resizes the window, then sets persisted attribs which include size mode. I would still like to land that but I'll file it in another bug.
Assignee | ||
Comment 75•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/b96de58efb5d
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Comment 76•14 years ago
|
||
OK...with the latest hourly (with this patch), the grey is gone (yay!), but now I get a completely white screen for 1-2 seconds when I open Firefox. It seems that the basic problem still hasn't been resolved (regardless of color).
Assignee | ||
Comment 77•14 years ago
|
||
(In reply to comment #76) > OK...with the latest hourly (with this patch), the grey is gone (yay!), but now > I get a completely white screen for 1-2 seconds when I open Firefox. It seems > that the basic problem still hasn't been resolved (regardless of color). This related to opening to the maximized state, or in general?
Comment 78•14 years ago
|
||
In general.
Assignee | ||
Comment 79•14 years ago
|
||
(In reply to comment #78) > In general. Do you see it with the menu bar enabled?
Comment 80•14 years ago
|
||
Yes, it covers everything from status bar to menu bar.
Assignee | ||
Comment 81•14 years ago
|
||
(In reply to comment #80) > Yes, it covers everything from status bar to menu bar. How does the behavior compare with 3.6?
Assignee | ||
Comment 82•14 years ago
|
||
I think I see what you're talking about. In 3.6, the initial paint seems to happen before the window fades in, but in 4.0, it seems to be delayed until after, so I see the white background briefly before content fills in.
Comment 83•14 years ago
|
||
Isn't this causing slow cold start?
Assignee | ||
Comment 84•14 years ago
|
||
(In reply to comment #83) > Isn't this causing slow cold start? We don't have ts cold for 3.6 on winnt 6.1, but as far as ts is concerned, the two branches match up. So this seems to have something to do with initial painting. I went back and tested a few older builds. I see the delayed initial paint all the way back to an alpha in feb.. Having the titlebar enabled seems to make this easier to notice, since the white area stretches all the way to the top of the window. I'll file this in a new bug.
Comment 85•14 years ago
|
||
Jim, Did you file a bug for comment 74?
Assignee | ||
Comment 86•14 years ago
|
||
(In reply to comment #85) > Jim, Did you file a bug for comment 74? bug 594821
Assignee | ||
Comment 87•14 years ago
|
||
(In reply to comment #86) > (In reply to comment #85) > > Jim, Did you file a bug for comment 74? > > bug 594821 ah, sorry. no not yet. will file and post back.
Assignee | ||
Comment 88•14 years ago
|
||
(In reply to comment #87) > (In reply to comment #86) > > (In reply to comment #85) > > > Jim, Did you file a bug for comment 74? > > > > bug 594821 > > ah, sorry. no not yet. will file and post back. bug 594881
Comment 89•14 years ago
|
||
While this has fixed the grey. I'm seeing a long (duration) white screen.
Comment 90•14 years ago
|
||
(In reply to comment #89) > While this has fixed the grey. I'm seeing a long (duration) white screen. same here
Assignee | ||
Comment 91•14 years ago
|
||
(In reply to comment #90) > (In reply to comment #89) > > While this has fixed the grey. I'm seeing a long (duration) white screen. > > same here Possibly a dupe of bug 594821? Can you try disabling jump list updates to see if it helps. (browser.taskbar.lists.enabled -> false) If that doesn't help, we also isolated a delayed paint issue in bug 594821. Maybe you could test a few older builds to see if this is the same regression I'm seeing? http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/05/ May 23 was when this showed up.
Comment 92•14 years ago
|
||
(In reply to comment #61) > SetSizeMode(0) > SetSizeMode(0) > SetSizeMode(0) > SetSizeMode(0) > Move(604, 248) > SetSizeMode(0) > SetSizeMode(0) -> normal > Resize(374, 430, 1) > ResizeClient(0, 0, 358, 422, 0) > ResizeClient(0, 0, 358, 422, 0) > Show(1) > SetSizeMode(2) -> maximized > ResizeClient(0, 0, 2560, 1568, 0) > Show(1) > > Hmm, we do get a resize while visible before setting the size mode. I'll have > to track down who is making these calls. Filed bug 604861 for this.
You need to log in
before you can comment on or make changes to this bug.
Description
•