Closed Bug 105286 Opened 23 years ago Closed 20 years ago

viewport used as containing block for absolutely positioned elements instead of root (percentage height, %, bottom)

Categories

(Core :: Layout: Positioned, defect)

Product:
Core
Component:
Layout: Positioned
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED INVALID

People

(Reporter: gabriele_fava, Unassigned)

References

Details

Attachments

(4 files, 3 obsolete files)

The image required by Exercise.HTM
(deleted), image/jpeg
Details
reduced testcase from the HTML
(deleted), text/html
Details
same but with positioned <body>
(deleted), text/html
Details
testcase showing the height issue....
(deleted), text/html
Details
The "background-image" property associated with "repeat: repeat" should renders a background image in the whole region under the control of the selector that is referred to. Mozilla instead (and ie 5.5 too, and I don't know what ie6 does) renders only the part that is visible on the screen at the rendering moment, the part that needs to be scrolled to be visible haven't a background.
->ImageLib
Assignee: dbaron → pavlov
Component: Style System → ImageLib
QA Contact: ian → tpreston
Do you have an example page that shows the problem?
Attached file The html page where the bug occurs (obsolete) (deleted) —
Attached file The style document for Exercise.HTM (obsolete) (deleted) —
Attached image The image required by Exercise.HTM (deleted) —
I'm sorry for the delay, I tried to reproduce the bug in other documents, but I wasn't able. So I posted the original document. What I see on "repeat" property (that is background-repeat) don't deal with the problem, because the "repeat" value is the default value. The problem is that only a part of the lateral background is rendered, exactly the part visible on the screen at the rendering moment. It seems that the height's percentage refers to the screen, non to the page.
Attached file reduced testcase from the HTML (deleted) —
Attachment #54351 - Attachment is obsolete: true
Attachment #54352 - Attachment is obsolete: true
Attached file same but with positioned <body> (deleted) —
The page has a div that's absolutely positioned with height:100%. That means its containing block is _not_ the body, which is statically positioned. Thus it's sized based on the viewport size. Making the body positioned makes the <div> size based on the body size, again correctly. Marking invalid; the behavior here is correct.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Are you sure it should be based on the viewport size?
Hmm. "If there is no such ancestor, the content edge of the root element's box establishes the containing block." So what is the root element in our case? <html>? How should we treat "position:absolute; bottom: 0"? Should it be at the very bottom of the page or at the bottom of the viewport when the page first loads? Reopening and to layout to decide all this.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
--> layout
Assignee: pavlov → attinasi
Status: UNCONFIRMED → NEW
Component: ImageLib → Layout
Ever confirmed: true
OS: Windows ME → All
QA Contact: tpreston → petersen
Hardware: PC → All
Summary: css "background-image" property: the images are not totally rendered → absolutely positioned 100% height div has height of viewport, not root element?
It's invalid to make the initial containing block positioned < http://www.w3.org/TR/REC-CSS2/visuren.html#containing-block >; but it could be that the initial containing block is <HTML>, not <BODY>; yes, it must be like that. Anyway, " 1. If the element has 'position: absolute', the containing block is established by the nearest ancestor with a 'position' other than 'static', If there is no such ancestor, the content edge of the root element's box establishes the containing block. " < http://www.w3.org/TR/REC-CSS2/visudet.html#containing-block-details >. That content edge is the document's edge, not the viewport. In your way it works, but it should works also leaving BODY static. It's an interpretation error, I think, but I'll ask to w3c's editors.
Component: Layout → ImageLib
OS: All → Windows ME
QA Contact: petersen → tpreston
Hardware: All → PC
Summary: absolutely positioned 100% height div has height of viewport, not root element? → css "background-image" property: the images are not totally rendered
The second URL you give says that the containing block is established by the root element, which in this case is HTML. I think Boris Zbarsky has established that this is either a layout bug or is not a bug.
Component: ImageLib → Layout
fixing QA, summary, OS/Platform.
OS: Windows ME → All
QA Contact: tpreston → petersen
Hardware: PC → All
Summary: css "background-image" property: the images are not totally rendered → absolutely positioned 100% height div has height of viewport, not root element?
Starting at the <div> and walking up to the nearest frame that IsPercentageBase does _not_ give us the <html> frame. Not exactly surprising...
"Starting at the <div> and walking up to the nearest frame that IsPercentageBase does _not_ give us the <html> frame. Not exactly surprising..." I'm sorry, I don't understand you. Are you talking about Mozilla source?
Yes. The frame corresponding to the div (the frame is the object that actually gets laid out and drawn) does not have the <html> frame as its containing block, basically. This feels like a layout bug to me.
Yes, I concur with you. By the way, I had the confirmation that "the content edge of the root element's box" must be the entire document edge, not the edge of the browser window. So this is a confirmed bug. Who takes it?
Target Milestone: --- → Future
*** Bug 126476 has been marked as a duplicate of this bug. ***
Summary: absolutely positioned 100% height div has height of viewport, not root element? → absolutely positioned 100% height div has height of viewport, not root element? [containing block]
If this is indeed a bug, does this also mean the only way to create an element which has, say, 90% the height of the viewport is with using "position: fixed" (since it's impossible to refer to the viewport in another way)?
So I suspect that the issue here is simply that the computed height of the <html> and the rendered height of the <html> do not match. Try setting "height: 100px" on the <html> and note that the positioned div is now 100px tall but the <html> block itself sizes based on the content...
Depends on: 15405
Hi, we've recently come across this bug. It seems that IE 6 is doing this correctly (but not doing other stuff though). Is this currently being work on or is there an estimated time that a fix might be landing?
*** Bug 157287 has been marked as a duplicate of this bug. ***
Ok. I'm a dunce when it comes to all the CSS talk. Just tell me, is this the correct bug for the following problem: <html style="height:100%"> <body style="height:100%"> <div><img height="125"...></div> <div style="height:100%;background:#FF"></div> </body> </html> The problem is that the 100% height div is rendered exactly as 100% + 125px (because it's under the image), and so we get 125px of scrolling on a blank document. This happens in standards, and quirks mode. Shouldn't 100% mean 100% of the viewport when the page isn't as tall as the viewport?
Attached file Like this (obsolete) (deleted) —
This is counter-intuitive to me. 100% equals more than 100%.
Actually, from a strict CSS point of view, the behavior of the testcase in comment 27 makes perfect sense. You've set the 'html' element to be the height of the viewport (okay, that part doesn't necessarily make sense, but it's what we do). Then you've set the 'body' element to be the height of its parent, which is 'html', which is the height of the viewport. Then you've set the height of the 'div' to equal the height of its parent, the 'body', so the 'div' is also the height of the viewport. To the pixel. You've placed content before it, so the 'div' gets shoved down that distance, but it's still as tall as the viewport-- which can be seen if you scroll down to the end of the document. 100% doesn't mean "fill in the remaining space," it means "make me as tall as my parent element," unless said parent has 'auto' height, in which case 100% means 'auto' for the sized element as well. See http://www.w3.org/TR/CSS2/visudet.html#propdef-height for details. I don't really think this is the same bug, although I could be wrong; I only glanced over the other discussion.
That testcase has nothing to do with this bug. Start with lack of an absolutely positioned element in the testcase (this bug is _only_ about absolutely positioned elements) and go from there.
Ok. I didn't know that the code that calculated heights for absolutely positioned DIVs was different than the code that calculated the height of other DIVs. Sorry to have bothered this bug.
*** Bug 172823 has been marked as a duplicate of this bug. ***
* The testcase titled 'testcase showing the height issue....' performs correctly. The content in garbage text overflow html element, as html has (implicitly) overflow: auto. Additional Comment #22 is not a correct analysis of the behavior. Additional Comment #28 From Eric A. Meyer It does make sense, Eric. Cascading Style Sheets, level 2 revision 1 states: "A UA may compute a percentage height on the root element relative to the viewport." http://www.w3.org/TR/CSS21/visudet.html#the-height-property But then you said, "I don't really think this is the same bug, although I could be wrong; I only glanced over the other discussion." You are correct. It is not the same bug. As your analysis states, it is not a bug at all, but a distraction. For more info on this, please see my testcase: http://dhtmlkitchen.com/experiment/height/ So what is supposed to happen? The div should have height: auto because "... The percentage is calculated with respect to the height of the generated box's containing block. If the height of the containing block is not specified explicitly (i.e., it depends on content height), and this element is not positioned, the value is interpreted like 'auto'..." Please make Mozilla do this exactly.
A few thoughts, although I only had a chance so far to skim your comment: * the containing block for absolutely positioned elements may be the initial containing block, which is not the root element (despite a contradiction in one part of CSS2) See CSS2 10.1. * We have hacks to make percentage heights work in a backwards compatible way in quirks mode, but they shouldn't be present in standards mode. See http://mozilla.org/docs/web-developer/quirks/
A third thought: * The scrollbars present on a window by default are not associated with 'overflow' on the root element, rather they are the scrolling mechanism required by CSS2 9.1.1: http://www.w3.org/TR/CSS21/visuren.html#q2
The horizontal scrollbar is not desirable at all. It can't be gotten rid of. I haven't given this much thought, though. How can one use right: 0; border-width: 1px and not have a horz scrollbar? "The containing block (called the initial containing block) in which the root element lives is chosen by the user agent." In Mozilla and IE, this is HTML. Look down below at the chart: For box generated by C.B. is established by body initial C.B. (UA-dependent) div1 body p1 div1 p2 div1 em1 p2 strong1 p2 So the initial C.B. in Mozilla is HTML, by choice, not rule.
Comment #33 We have hacks to make percentage heights work in a backwards compatible way in quirks mode, but they shouldn't be present in standards mode. I thought so at first, too. As I previously quoted, the css2.1 spec says, "A UA may compute a percentage height on the root element relative to the viewport." http://www.w3.org/TR/CSS21/visudet.html#the-height-property
The chart in comment 35 is wrong. The containing block for the <body> box is the <html> box. The UA-dependent part is what the containing block of the <html> box is. This is the case in IE6/Win in standards mode and in Mozilla. IE5.x/Win and IE6/Win in quirks mode treat <body> as the root element and the chart does apply to them as listed in comment 35.
That chart comes from section 10.1 of css2. It's just the same in revision 2.1. Am I to believe that the specification is wrong? http://www.w3.org/TR/CSS21/visudet.html
Yes. That text is clearly wrong. David, want to bring this up in the WG?
Oh, and note the mention of a "contradiction" in comment 33. That chart directly contradicts the earlier text in that same section.... The spec has been self-contradictory on this for a while now; I'm hoping the issues get ironed out before 1.2.1 exits CR...
Thanks for the clarification. Chart showing containment heirarchy: +---initial containing block---+ |+----------------------------+| || root (html) || || +------------------------+ || || | body | || || | | || || | | || || | | || || | | || || | | || || | | || || | | || || +------------------------+ || |+----------------------------+| +------------------------------+ The initial containing block is UA-dependent. HTML is the root Body is a containing block.
But now I am reading this: "... The root of the document tree generates a box that serves as the initial containing block for subsequent layout. ..." http://www.w3.org/TR/CSS21/visuren.html#initial-containing-block
WHat the fuck is the initial containing block? Is it a secret? Is it the document root? is it UA-dependent? Is it a secret? What's all this contradiction? Who's the expert here?
That part you just quoted is the second part of the contradiction David (who _is_ the expert here) referred to. As I understand, that prose will be cleaned up (read: edited to match section 10.1) in the next edition of the CSS 2.1 spec. The initial containing block is UA-dependant. The spec clearly says so in section 10.1 and that will continue to stand (again, this is based on what I've seen in the discussion on www-style@w3.org). In Mozilla it's the viewport, basically. It is not the document root. The document root is a DOM concept and is the root node of the DOM tree (<html> in HTML documents unless you're using a really broken browser like IE5.x/Win or IE6/Win in quirks mode (same thing); for those, the <body> is the root node of the DOM tree, as far as I can tell). The contradiction is between the normative definitions in section 10.1, the non-normative table you cited from the same section, and the normative text you cited in comment 42. The www-style@w3.org have some discussion on this, iirc... See the list archives (http://lists.w3.org/Archives/Public/). All of which is not relevant to this bug. What _is_ relevant is that whether it's a bug or not depends on what CSS 2.1 ends up saying when it's done. Trying to implement anything on the basis of a preliminary self-contradictory draft is silly.
So my diagram _is_ correct, right, Boris? (I'll accept your silence as affirmative). I'm going to email you and ask you to send me some resources that prove this, though. Not that I think you're lying, but I want to see proof. The documentation from css2 and css2.1 a total joke; its author a sadist.
The paragraph quoted in comment 42 is the inconsistency I mentioned in comment 33, and should be corrected in the next release of CSS 2.1 (by removal of a significant chunk of 9.1.2, I think).
The chart mentioned in comment 35 / comment 38 / comment 39 has already been corrected in internal CSS2.1 drafts:
http://www.people.fas.harvard.edu/~dbaron/css/test/sec090102 Shows that html element will stretch to fill the viewport vertically , even with html { height: 500px; } Not in quirks mode, the DTD is: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"> It is possibly related to this bug because the html element is automatically assuming the height of the viewport. I think what happened here is that somewhere, somebody filed a bug about "xxx element does not have n% height, instead it is as tall as possible" I further suppose that said bug was not marked invalid, as it should have been, and was incorrectly fixed. Tell me, is it so far fetched?
Comment 48 is bug 15405. It's a fundamental issue with the way the root of the and its immediate children are constructed and is not a result of a particular bugfix.
*** Bug 190063 has been marked as a duplicate of this bug. ***
Blocks: 196937
.
Assignee: attinasi → position
Component: Layout → Layout: R & A Pos
QA Contact: cpetersen0953 → ian
Target Milestone: Future → ---
*** Bug 216342 has been marked as a duplicate of this bug. ***
Summary: absolutely positioned 100% height div has height of viewport, not root element? [containing block] → viewport used as containing block for absolutely positioned elements instead of root (percentage height, %, bottom)
Depends on: 243519
Attachment #100836 - Attachment is obsolete: true
I don't see any of the test cases showing something that we do incorrectly. We seem to be consistent with the CSS specification, correct?
"which spec"? What we do is sorta wrong per CSS2.0, and maybe almost right per CSS2.1. Once bug 243519 is fixed, this bug should be revisited (hence the dependency).
*** Bug 253135 has been marked as a duplicate of this bug. ***
Just to carry this over from the dup. bug report (sorry, managed to miss this one on searching), now that the 2.1 spec is out (candidate recommendation), it only says the initial cb 'could' be the viewport. However, although this makes perfect sense for fixed position elements, it would be much more sensible to consider the canvas (that being the total area required to render the entire content) as the icb for absolutely positioned elements. If the viewport is used for both, absolute elements do not behave as expected, leading to interesting rendering effects and it becomes much harder (to the point of systematically having to 'patch' a page to behave sensibly) to specify an element that covers an area relative to the canvas but which grows with it's content. (Sorry if I have miss-used the term canvas).
Robert, the canvas is by definition infinite in the CSS spec.... As for the rest, using something that depends on the size of the content for the initial containing block leads to circular definitions (consider setting the height of the root element to 150% -- then it should be 150% the height of the initial containing block, and there is no way to make that consistent with your proposal). So the initial containing block needs to have an intrinsic size completely independent of the contents of the document. As things stand, Mozilla and Opera are working on interoperably implementing the viewport as the initial containing block, simply because there is nothing else reasonable to use.
This is INVALID per CSS2.1. CSS2.1 section 10.1 clearly says that the containing block of absolutely positioned elements that don't have a positioned ancestor is the initial containing block, which the working group agrees is, for desktop browsers, the viewport. (The spec doesn't actually say it is the viewport because there are theoretical cases where it wouldn't be, sigh.)
Status: NEW → RESOLVED
Closed: 23 years ago → 20 years ago
Resolution: --- → INVALID
I don't care what the elements are initially calculated against. All I care is that my css behaves as I expect it to. As such, when I specify that an element has a bottom attribute of 20px, I expect to see that element stretch all the way down to the bottom of whatever it is that controls how much the viewport needs to scroll, with a 20px space at the end. I can understand the argument about circular calculations and stuff but, well, quite simply, it can be done because I've seen it being done by Safari (and the source is available so maybe you should go take a peak...). Let me put this another way. The Safari behaviour seems to be completely css compliant and a sensible interpretation of the spec. In comparison, mozilla's interpretation reduces the capability of an html/css coder to control the layout of the page and causes unexpected and unnecessary 'visual effects' which require deep knowledge of how everything works to understand correctly. Now, you may argue that Safari is not CSS2.1 compliant (although I still hold that, in this respect, it is) but even if you argued that, then I would argue that the 2.1 spec is a backwards step and should be revisited. As it stands, and I have played with this a lot, with mozilla there is no way to create a div that has: 1) A height always at least that of the viewport minus some explicit offset 2) grows to accommodate content 3) has not had it's width and height explicitly coded (which breaks in all manner of ways and should be strongly discouraged for any major content holding element) Even if you consider Safari's method of rending to be wrong for some reason, this does not negate the fact that Mozilla's rendering is undeniably incorrect - allowing an element's content either to overflow or grow it's dimensions without redrawing it to show this growing visually. Also note that this behaviour is unique to absolutely positioned objects with no non-static ancestor meaning that the behaviour is radically different depending on the hierarchy and for no apparent reason. And what is the name for the area defined by the scroll bars? Not the canvas or the page so how about the View? After all, the window is termed the viewport.
I'll contact the Safari people to get their browser fixed. You can get the behaviour you describe using nested elements and min-height. I'm not sure what you mean by the drawing error, which testcase shows that? The box marked out by the scrollbars is the viewport.
nested elements and min-height will not work when the viewport is vertically larger than the min- height but the content of the element renders to less than the min-height. As you increase the height of the viewport further, the element in question does not grow with it but stays where it is, leaving an expanding patch of nothingness below itself. The two attachments linked to the dup. bug show a screen capture of one of the fuller pages of www.far-blue.co.uk. The Safari screenshot shows how things should be, with the translucent grey div coming all the way down to the bottom and leaving a 20px gap as specified in the style sheet. The mozilla screen shot shows that the same div is rendered with a gap from the bottom of the original viewport and is not re-rendered to accommodate the content which spills over it and continues down the *insert appropriate name e.g. canvas, page or view*. I am not even sure whether the grey div is actually resized or not to contain it's content but it certainly is not re-rendered if that is the case. I can re-post the attachments to this bug entry if people wish. The box marked out by the scroll bars is, indeed the viewport. I was referring to the space within which scrolling the scroll bars will move the viewport. I wish to know the name of the thing that totally encompasses the rendered content of all html (maybe even that specified to be 150% or another sily value) and which is used to calculate how much scrolling the viewport will need to do to allow the user to view it's entirety. It is this 'thing' (maybe described as the minimal canvas area required to hold rendered content?) that I argue should be the final reference for right and bottom attributes to absolutely positioned elements.
Robert, absolutely positioned elements affect the area you are talking about (if you position something "off the bottom of the page", the user can scroll to it. So you're suggesting a circular dependence again. Consider setting "bottom: -20px". With your proposal that would mean that the bottom of the element should be 20px below where you can scroll to. At the same time, you can scroll to the bottom of the element, per above. Which is impossible. The effect you want is easy to produce by setting "position: relative" on the root element, as I already told you to do in bug 253135.
And so then, bottom: 20px will be 20px *above* where you can scroll to? It's the natural converse of your statement, but it seems bizarre.
So should I reopen this one or file a different one on the issue where a window resize does not cause elements with viewport-based sizings to resize (in aviary)?
for a start, no, you can't gain the same results using position:relative on the root (or an ancestor) object. Because this object is only high enough to contain it's content, if the viewport is larger than the content the element we are talking about only expands to contain it's content, not all the way down to the bottom of the viewport. As for whether it is possible or not, I can only say it has to be possible because Safari (ad konqouror 3.2) does it. I cannot think of a better proof. Anyhow, if any negative value is specified for the bottom attribute, it should not grow the depth of the container (in this case root) element but overflow it. This is exactly what does happen with elements with a real ancestor so why do anything different with an element which is a child of the icb? As the scroll bars track the size of the root element (or whatever you wish to tall it), a negative value such as the one you describe should guarantee that the bottom of the affected element is not visible and you cannot scroll to it. Sounds sensible if slightly pointless. I don't see what the fundamental problem is with wishing to be able to specify that an element has it's bottom a known number of pixels (or whatever) from the bottom of the area viewable by the user. If there are no scroll bars, this should be the bottom of the viewport. If there are scroll bars, this should be the bottom of the viewport when the viewport is scrolled down as far as it will go.
I think I see the point. Since positioned elements aren't included in the block size, there isn't any circular dependency. The decision here appears to be that positions relative to the BODY element are viewport-relative. That's fine. I can get content-relative by wrapping my page in a DIV. If the same background is placed on the BODY and the DIV, then Robert's request is satisfied, no?
> And so then, bottom: 20px will be 20px *above* where you can scroll to? No. It will be 20px above the end of the root element (so 20px above where the in-flow content ends). > So should I reopen this one or file a different one on the issue where a > window resize does not cause elements with viewport-based sizings to resize > (in aviary)? First check whether it happens on trunk (I can't reproduce with a current trunk SeaMonkey build an a simple "bottom: 20px" testcase). If it does, please file a new bug, cc me. > As for whether it is possible or not, I can only say it has to be possible > because Safari (ad konqouror 3.2) does it. Really? What does it do for the "bottom: -20px" case? > I cannot think of a better proof You have yet to present evidence that it "does it" as opposed to "does something like it in a limited set of circumstances". > Anyhow, if any negative value is specified for the bottom attribute, it should > not grow the depth of the container Why not? A positive value for "top" _does_ grow the scrollable area, no? How is a negative bottom any different? What if a positive value is specified and the absolutely positioned element itself overflows, such that its overflow overflows the root too? > As the scroll bars track the size of the root element Except they don't. > I don't see what the fundamental problem is with wishing to be able to specify > that an element has it's bottom a known number of pixels (or whatever) from > the bottom of the area viewable by the user. Nothing, except CSS has no concept of "the bottom of the area viewable by the user". Please do feel free to take that up with the CSS working group.
The comments about backgrounds are from a while back while my bug report came in yesterday and was dup'd to this one so is prob a little confusing if you just read from the top :) To try and clarify (and there are two example screen shots showing the Safari and Mozilla versions of the rendering attached to my original bug report) this is what I tried to do: I have a div which is absolutely positioned. It has top, left, bottom and right attributes which, being an absolutely positioned element, I thought were relative to the total render area of the html, not the viewport. The div has a grey translucent background and variable content. The effect I wanted was that if the content was shorter than the viewport, the grey div would come down to a few pixels above the bottom of the viewport while if the content was longer, it would come down to a few pixels above the bottom of the viewport when the user has scrolled to the bottom of the rendered html. This is exactly what Safari does. (see the safari jpeg attachment in my original bug report) Mozilla, on the other hand, only renders down to the slight offset from the bottom of the viewport - no matter what the content of the div is doing. As a result, the content overflows the div and continues down. As you scroll, you can see the grey div has stopped in 'mid air' rather than carrying on down. I honestly don't think this is a valid behaviour however you look at it. Now, if the div was fixed, it seems very sensible that it has it's attributes relative to the viewport but then, it should also scroll with the viewport. If you try the trick of making the div have a relative ancestor, this works fine for any content longer than the viewport but fails to allow the div to extend down to near the bottom of the viewport when the content is shorter than the viewport. It would be a 30 second task to knock up a couple of example pages to show the various behaviours and some screen shots to show how mozilla vs Safari renders everything. Would that help? You can also see the problem by going to http://www.far-blue.co.uk, clicking on the 'RioVista' link (with an initially quite small mozilla window or with your text size at 200% to force the text to require scrolling). My suggestion is that calculating the right and bottom attributes of an absolute element with no ancestor should be relative to the final rendered size of the html, not the initial viewport.
a negative value on a top attribute does not push everything else down - right? so why should a negative value on bottom increase the scroll depth?
Robert, take such suggestions to the CSS working group, please. At the moment Mozilla implements what the spec says, so you're asking for us to break the spec or for the spec to change.
Status: RESOLVED → VERIFIED
> a negative value on a top attribute does not push everything else down - right? That's a bug. Bug 6976, in fact.
I'll take it up with the css committee :)
Nevermind on the resize issue. I note that the icb is the viewport size before application of scrollbars. Is that correct? Would it be possible to adjust the viewport when the scrollbars are added?
That's probably bug 243519
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: