Bug Report

On the home page, open DevTools and enable the device toolbar (phone/tablet icon). Choose a narrow phone viewport and refresh with the welcome offer and cookie notice visible. Compare with a desktop width and try both panels’ buttons. At what screen size do the panels start competing for space?

In DevTools → Elements, use the element picker to inspect each panel. In Styles, compare their positioning rules and bottom offsets; check their rendered heights too. Edit values directly in DevTools before changing the codebase, and try a width where the notice text wraps. Which positioning change makes both panels’ buttons accessible?

Find the mobile rule for .offer-popover in welcome-offer.component.scss. Move your successful DevTools experiment into the stylesheet, then reload because DevTools edits are temporary. Check narrow widths, enlarged text, and dismissing either panel first. How much bottom clearance does the offer need to stay above the cookie notice?

On checkout, use a different test email for each attempt so earlier orders do not confuse the result. Compare one deliberate click on Place Order with two quick clicks. In My Orders, search each email and compare the new orders’ items and totals. How many orders appeared after one click versus two quick clicks?

Open DevTools → Network, enable Preserve log, filter to Fetch/XHR, and select a slow throttling preset. Chrome DevTools throttling guide ↗ Repeat the rapid clicks and compare the order POST requests’ Payload tabs. In Elements, inspect the button while the first request is pending. Can another submission start before the first request finishes?

Find the submit handler and submitting state in checkout.component.ts, and the Place Order button in checkout.component.html. After making a change, verify one order for rapid clicks and that a failed request allows a retry; you can submit while Network is Offline, restore the connection, and retry. Restore normal throttling afterward. How could submitting both disable the button and guard the handler, while always allowing another attempt after failure?

On checkout, use a valid US address to avoid the separate international postal-code issue. Clear one required field and submit, then repeat with a different field. Leave two fields empty and correct only one. What does the feedback tell you about which fields still need attention?

Open DevTools → Network, filter to Fetch/XHR, and repeat an incomplete submission to see whether an order request is sent. In Elements, inspect the empty input and the error message. Search the project for the exact displayed error text. Where is the message chosen, and does that code keep track of which fields failed?

In checkout.component.ts, inspect the required-field checks; in checkout.component.html, find where the error is rendered. After your change, verify that correcting a field clears its error on revalidation and that valid checkout still works. Keep optional-region rules consistent with the State/Province report. How could you collect errors by field, display each beside its input, and associate the message with that input for accessibility?

On checkout, complete the Canadian example from the report and note the exact error. Compare the country selection, postal-code label, and message. Try a valid and an invalid format for both Canada and the US, keeping other required fields filled. Which inputs are rejected, and does the message describe the country you selected?

In DevTools → Network, filter to Fetch/XHR and repeat the Canadian submission. If an order POST appears, inspect its Payload and Response; if none appears, investigate the form’s validation. Search for the exact postal-code error text and inspect the condition that produces it. Does that check use the selected country?

In checkout.component.ts, set a Sources breakpoint at postal-code validation and inspect form.country, form.zip, and the pattern being tested. Retest valid and invalid formats after your change, distinguishing region errors from postal-code errors. How could the selected country determine both the validation rule and the format example shown when validation fails?

On checkout, select a US state, then switch to Canada. Repeat with France and compare with choosing a country once after a refresh. Note whether State/Province is a dropdown or text input and whether the old choice remains visible. Does a change in the displayed control tell you whether the previous value was cleared?

In DevTools → Elements, inspect the region options, label, and required attribute. Compare an empty region with a selected region for Canada, then try an empty region for France. Note which validation check blocks submission—the separate postal-code bug can also reject an address. Do the displayed choices, stored value, and required-field behavior agree?

Find onCountryChange in checkout.component.ts and pause there with a Sources breakpoint. Step through while watching form.state, then inspect the region validation and its template’s required binding. Verify the form value even if the postal-code bug still blocks submission. How could changing countries clear the old region and apply a consistent rule for when a new region is required?

On the plant listing, right-click Add to Cart for an available product and a sold-out product and choose Inspect. In DevTools → Elements, compare the disabled attribute, visible text, and accessible name. What tells the browser that one button is unavailable, and what tells the shopper why?

Inspect the stock binding and button text in product-card.component.html. Try disabled-button styling in DevTools → Styles before updating product-card.component.scss. Verify that available products still add to the cart and sold-out products stay unavailable. How could the button’s label, accessible name, and styling explain its stock status at the point where the shopper tries to act?

On the plant listing, open DevTools → Network, select the Img filter, and reload. Select the failed image request and find its Request URL in Headers. Compare that URL with a working image request. What differs between the addresses the browser is trying to load?

Search product-images.ts for the failed URL and compare its hostname with the working image URLs. Try correcting it, then reload to check the photo. For future failures, inspect the image element in product-card.component.html and the existing placeholder returned by resolveProductImage(null). How could you correct this image’s address and show a placeholder if another image fails, without repeatedly retrying a failed placeholder?

Reproduce the issue by opening Clear Cart and choosing Keep Items. Leave the page in its unresponsive state. Open DevTools → Elements and use the element picker over a button or link that no longer responds. What element does it select?

In Elements, inspect the selected element and its surrounding DOM. Use the page highlight to see how much space it covers, and check its position and dimensions in Styles or Computed. Did DevTools select the button or link you were trying to click? If not, what did it select?

If you find an element covering the page, temporarily add display: none in Styles and try clicking again. Search confirmation-dialog.component.ts for where that element is created or attached, then compare opening and closing the dialog. Reload to undo the temporary CSS change, and test cancellation, confirmation, and backdrop dismissal. What should happen to that extra element when the dialog component is destroyed?

Open DevTools → Application → Local Storage and select the app’s origin. Inspect cart_coupons before and after applying the same code twice; refresh the storage view if needed. Reload and compare the saved entries with the applied-coupon list. How many entries represent the same coupon, and do they survive a reload?

Find applyCoupon in cart.service.ts and follow the checks before it updates the applied-coupon collection. Compare the coupon returned by the lookup with the entries already in that collection. What is checked before adding a coupon, and is an already-applied code treated differently from a new one?

In applyCoupon, consider returning useful feedback before modifying the collection when the code is already present. Verify valid, invalid, and repeated codes, including capitalization and surrounding spaces; reload to check persistence and confirm discounts cannot exceed the subtotal. How could you recognize equivalent codes before saving another entry and keep the total from falling below zero?

Start with one sale item, quantity 1, and no promo codes. Compare the line-item amount with the subtotal. Repeat with a regular-price item. Which case adds up correctly?

In DevTools → Network, inspect the product request’s Preview or Response and find the sale product’s price information. Compare it with the line-item amount and subtotal you observed at quantity 1. Does anything in the product info explain the mismatch in price?

Compare the cart template’s line-item calculation with subtotal in cart.service.ts. After your change, test mixed sale and regular products and a promo code, then compare checkout with the saved order in My Orders. How could the shared subtotal use the same payable price as the line items while leaving the comparison price available for display?

In DevTools → Network, type mon and right-click its request → Throttle request. Slow only mon, leaving snake unthrottled (throttling guide ↗). Clear the input, type mon again, then replace it with snake while mon is pending. Does the list show snake results first, then switch back to mon?

The delayed mon response arrives after snake and replaces its results, even though the input still says snake. How can we ensure that only results for the latest search are displayed, even when responses can arrive out of order?

Find the search handler in header.component.ts and where it updates results after awaiting a response. Consider assigning each search change an increasing identifier. Retest with the same throttling rule, then clear the input or select a result while an older request is pending. Remove the rule afterward. If the user clears the search box or selects a result while a request is still pending, how will you stop that response from bringing the suggestions back?